azovdevmeetup 2016 | zero downtime — как релизить продукт миллионам...

Post on 13-Apr-2017

308 Views

Category:

Software

2 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Zero downtime –как релизить продукт миллионам пользователей

Виктор Димбровский, Аркадия

О себе

2

Виктор ДимбровскийАркадия

victor.dimbrovsky@arcadia.spb.ru

Работаю в Аркадии с 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

top related