Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AzovDevMeetup 2016 | Zero downtime — как релизить продукт миллионам пользователей | Виктор Димбровский

378 views

Published on

Участвуя в разработке высоконагруженной системы, разработчики сталкиваются со множеством интересных задач, неактуальных для небольших проектов. К примеру, имея большое количество активных пользователей, не все могут позволить себе приостановить работу системы на время релиза новой версии, что делает жизнь разработчиков гораздо увлекательнее даже в относительно простых проектах. А что если система состоит из большого набора веб-приложений, сервисов, постоянно взаимодействующих друг с другом, имеет публичный API, и т.д.? В докладе Виктор покажет, как можно обновить приложение незаметно для пользователей, определит основные факторы, которые могут помешать релизу без остановки приложения, а также даст практические советы по реализации.

Published in: Software
  • Be the first to comment

  • Be the first to like this

AzovDevMeetup 2016 | Zero downtime — как релизить продукт миллионам пользователей | Виктор Димбровский

  1. 1. Zero downtime – как релизить продукт миллионам пользователей Виктор Димбровский, Аркадия
  2. 2. О себе 2 Виктор Димбровский Аркадия victor.dimbrovsky@arcadia.spb.ru Работаю в Аркадии с 2013 года, тимлид в одной из команд, разрабатывающих платформу дистанционного обучения с большим количеством пользователей.
  3. 3. О проекте •Веб-платформа дистанционного обучения •Более 4 млн активных пользователей •Пользователи из Европы и США •Доступ 24/7 3
  4. 4. Доступность системы Downtime – метрика, которая определяет период, в течение которого система не выполняет свои основные функции Uptime – метрика, которая определяет период, в течение которого система доступна и выполняет свои функции. 4
  5. 5. Доступность системы Downtime = 1/20 = 5% Uptime = 19/20 = 95% 5 19 дней 1 день Online Offline
  6. 6. Допустимый downtime Гарантированный uptime >= 99.9% Допустимый downtime ~ 8 часов 46 минут в год ~ 44 минуты в месяц https://uptime.is/99.9 6 Online Offline
  7. 7. Причины простоя 7 Программные проблемы Аппаратные проблемы Форс-мажор
  8. 8. Задача Устранить или минимизировать все возможные факторы, которые могут привести к простою системы 8 OPS Development
  9. 9. Зоны ответственности Эксплуатация системы в штатном режиме Обеспечение высокого качества продукта Релиз новой версии 9
  10. 10. 10 Это downtime, а во время downtime-а где-то грустит котёнок
  11. 11. Формула успешного релиза 11
  12. 12. Сделайте релиз рутиной 12
  13. 13. Убедитесь, что процесс релиза прозрачен для всех его участников 13
  14. 14. Максимально подробно спланируйте и задокументируйте процесс релиза 14
  15. 15. Стратегия 15
  16. 16. Меньше и чаще 16 Небольшие и частые релизы несут в себе меньше рисков
  17. 17. Ничего лишнего 17 Всё, что может быть сделано безотносительно релиза, должно остаться за пределами релиза.
  18. 18. Что нам готовит день грядущий? 18 Подробно изучите изменения в новом релизе, рассмотрите потенциальные риски.
  19. 19. Что важнее: качество или сроки? 19 ¯_(ツ)_/¯
  20. 20. Обновляйтесь в период минимальной нагрузки 20 Меньше пользователей могут заметить нестабильность в работе системы и проблемы, в случае из возникновения.
  21. 21. Основной сценарий и запасной план 21 Список всех необходимых работ, последовательность их выполнения, план на случай наступления риска, и т.д. Определите необходимые ресурсы и назначьте менеджера релиза.
  22. 22. Коммуникация важна как никогда! 22
  23. 23. Нет предела совершенству 23 Всегда выполняйте работу над ошибками.
  24. 24. Разработчикам 24
  25. 25. Начните думать о своём коде с точки зрения релиза 25 Как вы собираетесь это релизить? Установите очередность, определите, что требуется для обновления (обновить код, базу, и т.д.)
  26. 26. Одна задача — один компонент 26 Разбейте систему на компоненты, которые можно релизить независимо — single deployable.
  27. 27. Помните об обратной совместимости! 27 Устраните потенциальные проблемы несовместимости уже обновлённого компонента и ещё не обновлённых.
  28. 28. Наш опыт 28
  29. 29. Особенности релиза - Одно основное веб-приложение и множество неосновных компонентов - Каждые 2 недели - Утро субботы - Практика пилотного релиза - 1 неделя после релиза – мониторинг - Приостановка некоторых компонентов на период обновления системы 29
  30. 30. Особенности релиза - Используется собственное решение для развертывания новой версии - Процесс обновления максимально автоматизирован - Процесс тестирования конфигурации автоматизирован - Балансировка нагрузки и несколько копий каждого веб-приложения 30
  31. 31. Упрощённая схема релиза 31 1 Обновление БД до обновления приложения Обновление всех сервисов и компонентов, кроме основного приложения Обновление основного приложения для пилотных пользователей Обновление основного приложения для пилотных пользователей Обновление БД после обновления приложения 2 3 4 5 День релиза 1 неделя до релиза 1 неделя после релиза Развертывание новых компонентов Изменения данных по запросу 1 Часть релиза Не включено в релиз
  32. 32. Обратная сторона - Нужно больше думать!  - Дополнительные издержки - Больше бюрократии 32
  33. 33. Выводы - Релиз крупного веб-приложения — это всегда интересная инженерная задача - Сложно, но возможно! - Семь раз отмерь — один раз отправь в релиз - Результат оправдывает издержки 33
  34. 34. Виктор Димбровский, Аркадия Q & A

×