Как развивать облачный хостинг и сервис: обеспечиваем бесперебойную работу и добавляем возможности

18bdf86de9823432a66332c9ef2df6b8

Если использовать популярное сравнение, то развитие облачного сервиса — это задача, схожая с заменой мотора на летящем самолете. Однако альтернативы нет. Вы просто безнадежно отстанете, в случае если не будете меняться.

18bdf86de9823432a66332c9ef2df6b8 800x392 Как развивать облачный хостинг и сервис: обеспечиваем бесперебойную работу и добавляем возможности

Облачный хостинг в Украине: создание бесперебойной работы

Нагрузки

В случае если ваш проект работает в B2B (то есть именно для компаний, но не отдельных пользователей), то прогнозировать его нагрузку весьма просто. У нее не бывает внезапных скачков вроде хабраэффекта. Если говорить про торговлю, то в течение года есть два известных пика: 8 марта и перед новогодними праздниками. Пики составляют пару десятков процентов.

Так как нагрузка меняется мало, нет большой потребности в эластичности, которую дают разные PaaS. Поэтому вместо того, чтобы использовать облачный хостинг можно арендовать dedicated серверы. По всей видимости, при постоянно высокой нагрузке это — наиболее оптимальное решение.

В случае если все идет хорошо, то база пользователей непрерывно растет. Это постоянный тренд, каждый месяц объем баз и нагрузка повышается на 5-10%. На практике это означает, что каждые пару месяцев вы должны ставить новые серверы или улучшать архитектуру сервиса (или все вместе).

Но главная причина, по которой следует иметь солидный запас по нагрузке — ошибки. Некоторые ошибки возникают на продакшн площадке совместно с обновлениями.
Остальные ошибки терпеливо ожидают своего шанса. Больше всего проблем на практике вам могут доставить экзотические шаблоны, зацикливающие код печати документов.

В связи с этим вам следует определить минимальный запас по производительности для всех компонентов и серверов — в два раза. В подавляющем большинстве случаев он позволяет клиентам нормально работать, даже когда внутри возникли какие-нибудь проблемы.

Нет потребности сразу готовить архитектуру на очень высокие нагрузки. В мире B2B ничего мгновенно не происходит, и при плавном росте хватает времени постепенно адаптировать вашу архитектуру под растущую постоянно нагрузку.

Не нужно тратить очень много времени, чтобы подготовиться к будущим очень высоким нагрузкам. Так как, скорее всего, потом все равно придется все переделывать.

Развитию архитектуры больше всего мешают или помогают технологии. Правильные технологии жизнь делают приятной и простой. Неправильные же приносят страдание и боль.

Если технология вообще не работает, желательно заменить ее как можно быстрее.

59a6354ee1688b0ecd288de8c2dfdb13 Как развивать облачный хостинг и сервис: обеспечиваем бесперебойную работу и добавляем возможности

Релизы

Важная задача развития любого продукта — это поддерживать его сбалансированым.

Сильно уменьшить хаос помогает понимание того, что все фичи делятся на три категории.

  • Платформенные фичи. Они внешне ничего не дают пользователям, часто даже мешают, так как их выпуск потенциально связан с наиболее суровыми тормозами и глюками. Однако если регулярно не реализовывать улучшения платформы, то довольно скоро продукт обязательно зашатается на тоненьких ножках и просто обвалится под растущей нагрузкой.
  • Переработки функциональности. Они не дают каких-то новых возможностей, однако приводят в порядок все то, что было сделано плохо. Переработки часто вызывают массовое страдание у всех пользователей, привыкших работать по-старому. Делать их все же надо, так как без них продукт очень быстро станет крайне запутанным и доступным для понимания исключительно для избранных.
  • Реально новые фичи. Да, пользователи приобретают решение своих задач, а вовсе не набор фичи. Но в конечном итоге определенный продукт выбирают из-за набора возможностей, которые приблизительно соответствуют всем задачам пользователя. Новые фичи появляться должны непрерывно.

Эти три категории фич уже проще балансировать. Необходимо просто организовать нормальную разработку в три отдельных параллельных потока. Как их лучше группировать в релизы?

Главная рекомендация из нашего опыта — никогда не объединяйте в одном единственном обновлении платформенные изменения и новые фичи. Эти объединенные релизы получаются крайне сложными, их сложно тестировать и сложно готовить. Поэтому мы делим релизы на функциональные и платформенные.

Особенность современных платформенных релизов — под сильной нагрузкой, на реальных данных пользователей, что-нибудь может пойти неправильно. Поэтому мы их делаем откатываемыми. Если появляются любые проблемы, за пару минут возвращается первая версия, а команда разработки готовит еще одну попытку.

Функциональные релизы труднее делать откатываемыми. В основном, они требуют изменений в схеме базы данных и конверсий данных, в связи с чем вернуть старую версию так просто не получится. Однако в этом нет потребности — функциональный релиз гораздо проще качественно протестировать.

Хитрость: массивные обновления желательно выкатывать на выходных. В эти дни в сервисе работает в разы меньше пользователей.

cloudhost1 Как развивать облачный хостинг и сервис: обеспечиваем бесперебойную работу и добавляем возможности

Вывод

Мы показали методики и подходы непрерывного развития удачно функционирующего облачного сервиса. Итак, еще раз три ключевых правила работы при постоянных обновлениях:

  • Ключевая причина, по которой следует иметь хороший запас ресурсов при нагрузке — возможные различные ошибки разработки, а вовсе не возможный будущий рост количества пользователей. Не нужно тратить время, чтобы активно готовиться к будущим очень высоким нагрузкам.
  • Нет смысла очень долго пытаться заставить нормально работать компоненты и внешние библиотеки: если технология вообще не работает, то лучше всего ее заменить как можно раньше.
  • Если вы все уже сделали и полностью готовы к обновлениям, то никогда в одном релизе не объединяйте платформенные изменения и новые фичи.

Поделитесь с друзьями



Оставить комментарий

apteka mujchine for man ukonkemerovo woditely driver.