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

1. Zero downtime –
как релизить продукт миллионам пользователей
Виктор Димбровский, Аркадия

2. О себе
2
Виктор Димбровский
Аркадия
victor.dimbrovsky@arcadia.spb.ru
Работаю в Аркадии с 2013 года, тимлид в
одной из команд, разрабатывающих
платформу дистанционного обучения с
большим количеством пользователей.

3. О проекте
•Веб-платформа дистанционного
обучения
•Более 4 млн активных пользователей
•Пользователи из Европы и США
•Доступ 24/7
3

4. Доступность системы
Downtime – метрика, которая определяет
период, в течение которого система не
выполняет свои основные функции
Uptime – метрика, которая определяет
период, в течение которого система
доступна и выполняет свои функции.
4

5. Доступность системы
Downtime = 1/20 = 5%
Uptime = 19/20 = 95%
5
19 дней 1 день
Online Offline

6. Допустимый downtime
Гарантированный uptime >= 99.9%
Допустимый downtime
~ 8 часов 46 минут в год
~ 44 минуты в месяц
https://uptime.is/99.9
6
Online Offline

7. Причины простоя
7
Программные
проблемы
Аппаратные
проблемы
Форс-мажор

8. Задача
Устранить или минимизировать все
возможные факторы, которые могут
привести к простою системы
8
OPS Development

9. Зоны ответственности
Эксплуатация системы в штатном
режиме
Обеспечение высокого качества
продукта
Релиз новой версии
9

10. 10
Это downtime, а во время downtime-а где-то грустит котёнок

11. Формула успешного
релиза
11

12. Сделайте релиз рутиной
12

13. Убедитесь, что процесс релиза
прозрачен для всех его
участников
13

14. Максимально подробно
спланируйте и
задокументируйте процесс
релиза
14

15. Стратегия
15

16. Меньше и чаще
16
Небольшие и частые релизы несут в себе меньше рисков

17. Ничего лишнего
17
Всё, что может быть сделано безотносительно релиза, должно
остаться за пределами релиза.

18. Что нам готовит день
грядущий?
18
Подробно изучите изменения в новом релизе, рассмотрите
потенциальные риски.

19. Что важнее: качество или
сроки?
19
¯_(ツ)_/¯

20. Обновляйтесь в период
минимальной нагрузки
20
Меньше пользователей могут заметить нестабильность в работе
системы и проблемы, в случае из возникновения.

21. Основной сценарий и запасной
план
21
Список всех необходимых работ, последовательность их
выполнения, план на случай наступления риска, и т.д.
Определите необходимые ресурсы и назначьте менеджера
релиза.

22. Коммуникация важна как
никогда!
22

23. Нет предела совершенству
23
Всегда выполняйте работу над ошибками.

24. Разработчикам
24

25. Начните думать о своём коде с
точки зрения релиза
25
Как вы собираетесь это релизить? Установите очередность,
определите, что требуется для обновления (обновить код, базу,
и т.д.)

26. Одна задача — один
компонент
26
Разбейте систему на компоненты, которые можно релизить
независимо — single deployable.

27. Помните об обратной
совместимости!
27
Устраните потенциальные проблемы несовместимости уже
обновлённого компонента и ещё не обновлённых.

28. Наш опыт
28

29. Особенности релиза
- Одно основное веб-приложение и
множество неосновных компонентов
- Каждые 2 недели
- Утро субботы
- Практика пилотного релиза
- 1 неделя после релиза – мониторинг
- Приостановка некоторых компонентов на
период обновления системы
29

30. Особенности релиза
- Используется собственное решение для
развертывания новой версии
- Процесс обновления максимально
автоматизирован
- Процесс тестирования конфигурации
автоматизирован
- Балансировка нагрузки и несколько
копий каждого веб-приложения
30

31. Упрощённая схема релиза
31
1
Обновление БД до
обновления
приложения
Обновление всех сервисов и
компонентов, кроме
основного приложения
Обновление основного
приложения для пилотных
пользователей
Обновление основного
приложения для пилотных
пользователей
Обновление БД
после обновления
приложения
2 3 4 5
День релиза
1 неделя
до релиза
1 неделя
после релиза
Развертывание новых
компонентов
Изменения
данных по
запросу
1 Часть релиза
Не включено в релиз

32. Обратная сторона
- Нужно больше думать! 
- Дополнительные издержки
- Больше бюрократии
32

33. Выводы
- Релиз крупного веб-приложения — это
всегда интересная инженерная задача
- Сложно, но возможно!
- Семь раз отмерь — один раз отправь в
релиз
- Результат оправдывает издержки
33

34. Виктор Димбровский, Аркадия
Q & A