Если через месяц после окончания гарантийного срока в чайник попробовать добавить функцию кофеварки — и он вдруг сломается… Да, вот тогда это будет вполне верная аналогия.
Мой личный опыт работы в суппорте хостинга. Клиент и тех. поддержка:
— Поменяйте нам, пожалуйста, одну строчку (телефон) в одном файлике на сайте! Очень срочно!
— Мы не вмешиваемся в контент пользователей, это — задача Вашего разработчика.
— Он у нас уволился…
— Поменяйте сами. Мы все подробно расскажем, как зайти по FTP, как обновить и т.п.
— Мы не умеем! Надо очень срочно! Мы заплатим! Помогите!
Это — типичный если не ежедневный, то уж точно еженедельный (по несколько раз) диалог…
Этот кейс хорошо подтверждает тезис о том, что Россия — страна, в которой наиболее быстро читается любое пользовательское лицензионное соглашение. ;))
Если серьезно, то, я думаю, Вы несколько лукавите.
1. Был баг, который Вы терпели в течение года? Или не замечали? Он был критичным, и его не исправляли?
2. Когда заканчивается период действия обновлений, приходит письмо о том, что надо купить продление. Со всеми условиями и т.п. Оно быстро и аккуратно удаляется в корзину или все-таки прочитывается?
1. Льготное продление (в первый месяц по истечение года, им пользуются почти все, кто вообще обновляется) — 22% от стоимости лицензии. Это — чуть больше 1/5, а не «полная».
2. Масса примеров, когда люди покупают продление через 2-3 года после окончания действия обновлений.
Делают они это явно не из-за косяков (а как тогда работают эти годы?), а для того, чтобы получить новый функционал.
Помогают разные дополнительные инструменты. Например, freeze файловой системы (если она это поддерживает). Мы так без проблем снэпшотами бэкапим RAID-10. Задержка — единицы секунд (ночью). Для клиентов практически незаметно.
Для восстановления MySQL — дамп, созданный mysqldump + «проигрывание» бинарных логов.
Не знаю точно, но, наверняка, для MongoDB есть подобные инструменты.
P.S. В общем, все это сводится к тому, что с бэкапами и репликацией в разных AZ лучше, чем без них. ;))
В итоге очень легко минимизируете время простоев. Вот, например, наш собственный пример, с вязанный как раз с последним инцидентом в Ирландии: habrahabr.ru/company/bitrix/blog/125932/
В итоге очень легко минимизируете время простоев. Вот, например, наш собственный пример, с вязанный как раз с последним инцидентом в Ирландии: habrahabr.ru/company/bitrix/blog/125932/
У них (в отличие от того же Facebook, хоть и не совсем корректно сравнивать) очень мало инструментов для построения более полных социальных связей.
Да, они хотят соц. сеть. Потому что это — и лояльные пользователи, и новые пользователи, и бОльшее время, проведенное на сайте. В общем, все то, что хочет получить любой сервис.
Who to follow, Similar to you… Activity — логичное продолжение.
Сейчас каждая нода произвольно пишет файлы на локальную файловую систему.
Каждая нода синхронизируется друг с другом с помощью csync2, утилит inotify и пары собственных скриптов.
В будущем планируется бОльшую часть статики вынести в облачное хранилище (например, в тот же Amazon S3). Тогда ничего синхронизировать уже не придется.
Поддержка основных хранилищ (Amazon S3, Google Storage, MS Azure) непосредственно в платформе «1С-Битрикс» появится в ближайшем релизе 10.5 осенью.
Про наши старые машины — не знаю. Думаю, уже и не будем их поднимать, а развернем всю инфраструктуру заново с некоторыми корректировками — это будет проще.
> Наверное стоило бы разместить сервер мониторинга(вместе с ненагруженным бэкапом) в другой зоне, тогда и накладные расходы не такие большие и надёжность выше?
Конкретно у нас — до терабайта, несколько сот гигабайт. Бэкап в другом датацентре сделать, конечно, можно. Только, вот, восстановление из бэкапа — плохая тема. Будет потеря последних актуальных данных. Для нас это практически недопустимо.
Что касается Амазона, то на моей памяти — это вторая подобная авария за последнее время. Предыдущая была в апреле и затронула один из регионов в Штатах.
У схемы с физическими серверами в разных ДЦ есть свои минусы:
— Цена.
— Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
— Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).
А то звучит то «платформа», то «админка». А это — несколько разные вещи. В разной степени влияющие на возможность развития проекта.
Мой личный опыт работы в суппорте хостинга. Клиент и тех. поддержка:
— Поменяйте нам, пожалуйста, одну строчку (телефон) в одном файлике на сайте! Очень срочно!
— Мы не вмешиваемся в контент пользователей, это — задача Вашего разработчика.
— Он у нас уволился…
— Поменяйте сами. Мы все подробно расскажем, как зайти по FTP, как обновить и т.п.
— Мы не умеем! Надо очень срочно! Мы заплатим! Помогите!
Это — типичный если не ежедневный, то уж точно еженедельный (по несколько раз) диалог…
Если серьезно, то, я думаю, Вы несколько лукавите.
1. Был баг, который Вы терпели в течение года? Или не замечали? Он был критичным, и его не исправляли?
2. Когда заканчивается период действия обновлений, приходит письмо о том, что надо купить продление. Со всеми условиями и т.п. Оно быстро и аккуратно удаляется в корзину или все-таки прочитывается?
1. Льготное продление (в первый месяц по истечение года, им пользуются почти все, кто вообще обновляется) — 22% от стоимости лицензии. Это — чуть больше 1/5, а не «полная».
2. Масса примеров, когда люди покупают продление через 2-3 года после окончания действия обновлений.
Делают они это явно не из-за косяков (а как тогда работают эти годы?), а для того, чтобы получить новый функционал.
Помогают разные дополнительные инструменты. Например, freeze файловой системы (если она это поддерживает). Мы так без проблем снэпшотами бэкапим RAID-10. Задержка — единицы секунд (ночью). Для клиентов практически незаметно.
Для восстановления MySQL — дамп, созданный mysqldump + «проигрывание» бинарных логов.
Не знаю точно, но, наверняка, для MongoDB есть подобные инструменты.
P.S. В общем, все это сводится к тому, что с бэкапами и репликацией в разных AZ лучше, чем без них. ;))
В итоге очень легко минимизируете время простоев. Вот, например, наш собственный пример, с вязанный как раз с последним инцидентом в Ирландии: habrahabr.ru/company/bitrix/blog/125932/
В итоге очень легко минимизируете время простоев. Вот, например, наш собственный пример, с вязанный как раз с последним инцидентом в Ирландии: habrahabr.ru/company/bitrix/blog/125932/
У них (в отличие от того же Facebook, хоть и не совсем корректно сравнивать) очень мало инструментов для построения более полных социальных связей.
Да, они хотят соц. сеть. Потому что это — и лояльные пользователи, и новые пользователи, и бОльшее время, проведенное на сайте. В общем, все то, что хочет получить любой сервис.
Who to follow, Similar to you… Activity — логичное продолжение.
Сделают аккуратно — будут молодцы.
Каждая нода синхронизируется друг с другом с помощью csync2, утилит inotify и пары собственных скриптов.
В будущем планируется бОльшую часть статики вынести в облачное хранилище (например, в тот же Amazon S3). Тогда ничего синхронизировать уже не придется.
Поддержка основных хранилищ (Amazon S3, Google Storage, MS Azure) непосредственно в платформе «1С-Битрикс» появится в ближайшем релизе 10.5 осенью.
Да, конечно. Выводы сделали.
У PaaS — значительно более узкая ниша. Этот продукт рассчитан на разработчиков, а не на массового пользователя.
Как следствие — потенциально меньше «возможностей» для падений. А также — меньше возможных отзывов о падениях, если они все-таки произойдут.
Что касается Амазона, то на моей памяти — это вторая подобная авария за последнее время. Предыдущая была в апреле и затронула один из регионов в Штатах.
— Цена.
— Не гибкая схема. Падает точка входа — ее изменение связано с изменением DNS и т.п. А это — время.
— Очень плохое масштабирование — в обе стороны: как увеличение ресурсов, так и их уменьшение (если прогнозируется спад нагрузки).