Деплоить в прод при каждом изменении может быть страшно, но не деплоить в прод напрямую — ещё страшнее.
Именно этот процесс я применял в Amazon, руководя командой, которая выкатывала релизы для сотен миллионов клиентов. В рамках консалтинга я помог инженерным командам перейти от релизов по расписанию раз в две недели к выкладке при каждом merge.
Начнём с очевидного:
Вы вызовете сбой. Это не вопрос «если», а вопрос «когда».
Никакое количество юнит-тестов, интеграционных тестов, догфудинга, end-to-end — да чего угодно — или жертвоприношений богам деплоя не выловит все баги.
Фича, которую вы тестировали неделю назад, не тестировалась вместе с последними изменениями вашего коллеги.
Вы тестировали свою фичу против предпродакшн-версии сервиса коллеги, а та с тех пор изменилась и теперь содержит обратно несовместимое изменение.
Чем дольше вы ждёте, тем больше изменений накапливается в релизе. Если потребуется откат, вам придётся откатывать изменения, накопленные за две недели, а не за час-другой.
Если принять, что сбой неизбежен, то вкладывать огромные ресурсы в QA релиза теряет всякий смысл. Вместо этого стоит направить ресурсы на мониторинг и наблюдение за релизом и быть готовыми реагировать на сбой, когда он случится.
Теперь о том, как к этому прийти:
Предварительные требования:
CI/CD
Тестирование гораздо менее важно, чем вы думаете. Тесты не могут доказать, что ваше изменение безопасно в проде. Ничто не может. Задача тестов — сделать сбой дешёвым. Баг, пойманный в CI, обходится в минуты. Баг, пойманный в проде, стоит вам вечера, потраченного на откат.
Поэтому прогоняйте полный набор тестов при каждом merge — или хотя бы в рамках пайплайна: юнит, интеграционные, end-to-end. Чем дальше баг проходит по пайплайну, тем дороже обходится его устранение.
Мониторинг/Наблюдаемость
Суть в том, чтобы ловить регрессии как можно раньше. Для этого нужен отличный мониторинг. Это включает в себя:
- метрики: ошибки, задержки, доступность
- логи с корреляционными идентификаторами
- алерты для sev-3 и sev-2 (с пейджингом), привязанные к первым двум пунктам
Настройка порогов алертов — это в равной степени искусство и наука. Это баланс между чувствительностью и скоростью вашей реакции на реальный инцидент. Целевое время срабатывания алерта для sev-2 — 5–10 минут.
Поначалу вы, скорее всего, ошибётесь и сделаете алерты слишком чувствительными. К сожалению, это познаётся в основном методом проб и ошибок, так что первое время вас наверняка пару раз разбудят в 2 часа ночи.
Фичефлаги
Любое рискованное изменение стоит выкатывать за фичефлагом или удалённой конфигурацией. Фичефлаг позволяет отключить и откатить изменение за несколько минут, не откатывая весь деплой. Кроме того, если ваш сервис фичефлагов это позволяет (а он должен), можно раскатывать фичу постепенно — по проценту пользователей или по когортам, что ещё сильнее снижает влияние плохого изменения.
Это позволяет разделить деплой кода и его активацию. Тонкий момент, но он кардинально меняет правила игры в плане снижения рисков.
Примечание: вам понадобится процесс очистки флагов. В идеале — заводить тикет на удаление для каждого созданного флага. Иначе, когда ваш сервис фичефлагов ляжет (а он ляжет), вы получите серьёзную регрессию. Спросите, откуда я знаю.
Автоматический откат (circuit breaker на время деплоя)
Circuit breaker на время деплоя — это функция, которая позволяет откатить развёртывание, если при раскатке по парку серверов вы видите определённое количество или процент ошибок. У большинства облачных провайдеров это включается простым чекбоксом.
Обратно совместимые изменения
Вы и так должны так делать, но деплой при каждом коммите вынуждает соблюдать это правило. Во время rolling-деплоя старая и новая версии будут работать одновременно. Каждое изменение должно работать вместе с предыдущей версией. Ваш трюк с деплоем в полночь, чтобы избежать этого, больше не работает.
Стратегии деплоя
Теперь, когда всё это настроено, давайте разберём несколько стратегий деплоя, которые помогут снизить риск при выкатке изменений.
One box (канарейка)
One box деплой выкатывает ваши изменения на одну машину из всего парка серверов. Это ограничивает влияние плохого изменения одним хостом.
Вы деплоите и оставляете изменение на какое-то время — через машину проходит небольшая доля общего трафика. На неё вы настраиваете мониторинг и алерты, которые сработают, если что-то сломается.
Rolling-деплой
Rolling-деплой позволяет раскатывать изменение постепенно, по процентам, так что при катастрофической ошибке вы заметите её до того, как она затронет все машины, и сможете начать откат.
Региональная раскатка
По мере роста компании у вас появятся деплои в нескольких регионах. Вместо того чтобы раскатывать изменения во всех регионах одновременно, можно сначала выкатить их в один конкретный регион — обычно с наименьшим трафиком.
Случаи, когда это не работает
App Store
Релиз мобильного приложения не совсем вписывается в этот подход. Очередь на ревью в App Store замедляет темп деплоя и требует другой стратегии.
Сертифицированные среды
Медицинские устройства, авионика, промышленные системы управления и т.д. Не получится непрерывно деплоить, если регулятор должен сертифицировать сборку.
On-prem / Self-hosted
Вы не контролируете обновление. Вы по-прежнему можете непрерывно деплоить всё, чем управляете, но каждое изменение нужно версионировать, а решение о внедрении принимает клиент.
С чего начать
Не делайте всё сразу. Порядок имеет значение:
- Добейтесь зелёного и быстрого CI. В идеале — менее 15 минут
- Настройте метрики и алерты на частоту ошибок, задержку и доступность. Это самая важная часть работы
- Прячьте любое рискованное изменение за флагом
- Добавьте one-box деплой и автоматический откат
- Удалите календарь релизов
- Найдите, чем занять освободившееся время, теперь, когда вам не нужно планировать релизы
Большинству команд, с которыми я работал, требуется около квартала, чтобы пройти весь этот путь. Инструменты — это лёгкая часть. Сложная часть — организационные процессы и разрушение иллюзии, что релизы по расписанию безопасны.
Если ваша команда сидит на календаре релизов и хочет с него слезть — это как раз то, чем я занимаюсь. Пишите мне в личку.
