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