Любое изменение в рабочей среде может повлиять на пользователей: новая версия сервиса, миграция базы данных, обновление мобильного клиента или переключение конфигурации. Выкатывая изменения для пользователей на прод, вы рискуете столкнуться с чем угодно: от битой кнопки до недоступности сервиса.Тесты снижают вероятность ошибки, но не воспроизводят весь набор данных, нагрузку и сочетания запросов в работающей системе.

Чтобы деплой прошёл без проблем, нужно подготовить воспроизводимый артефакт, проверить совместимость версий и заранее определить условия остановки или отката релиза. Подробнее об этих процессах и опыте работы с высоконагруженными системами рассказала команда RWB.

Деплой отвечает за доставку кода или собранного артефакта в проде. Релиз начинается тогда, когда новое поведение становится доступно пользователям. Эти события могут происходить одновременно, но если будете разделять — получите больше контроля.

Если вы выкатываете новую версию сервиса с дополнительными функциями, сначала функцию можно открыть сотрудникам, затем небольшой группе пользователей или отдельному региону. При этом вы можете отдельно управлять версией приложения и доступностью конкретной функции. Например, если проблема связана с функцией, её можно быстро выключить через флаг, а если сбой затрагивает весь сервис, вы возвращаете предыдущую версию приложения.

Держите в фокусе четыре параметра:

1. какой именно артефакт попадает в среду;
2. какая доля запросов или пользователей видит изменение;
3. по каким сигналам выкладка продолжается или останавливается;
4. сколько времени занимает возврат к рабочей версии.

Время восстановления тоже нужно определить заранее. Например, отключение функции через флаг должно занимать не более 1–5 минут, возврат к предыдущей стабильной версии — до 15 минут. Для сбоев, затрагивающих базу данных или требующих ручного вмешательства, устанавливают отдельное целевое время восстановления — например, 30–60 минут. Эти значения служат отправной точкой: уточняйте их с учётом критичности сервиса, архитектуры и требований бизнеса.

Одна из причин релизных сбоев скрывается между тестовой средой (стейджингом) и продом. Вы проверяете один контейнерный образ, а перед выходом в прод собираете его заново. Результат второй сборки может отличаться: обновилась незакреплённая зависимость, изменился базовый образ, очистился кеш или иначе отработал сборочный скрипт.

С подобной проблемой столкнулись и мы в RWB. При непрерывной интеграции и доставке (CI/CD) пайплайны для разных сред запускались независимо. Из-за повторной сборки в прод мог попасть образ, который не проходил проверку на стейджинге.

Мы перешли к переиспользованию одного артефакта. Во время первой сборки система вычисляет хеш содержимого репозитория и записывает его в метаданные контейнерного образа. На следующих этапах пайплайн ищет в реестре контейнерных образов артефакт с тем же хешем. Если содержимое исходников не изменилось, образ не собирается заново: система назначает ему тег нужной среды и разворачивает уже проверенную версию.

Для прода в RWB добавили отдельное правило. Если пайплайн не находит ранее собранный образ, выкладка завершается ошибкой. Правило находится непосредственно в коде пайплайна.

После внедрения этого подхода RWB еженедельно пропускает около 700 сборок. Это 30% сборок с включённой фичей и 5% общего числа сборок через CI/CD. Главное — между тестированием и продом сохраняется один и тот же исполняемый код.

Даже проверенный артефакт может повести себя иначе на реальном трафике. Помогает поэтапная доставка изменений — новая версия постепенно охватывает всё больше пользователей.

При канареечной выкладке новую версию сначала получает небольшая группа пользователей, а остальные продолжают работать со старой. Отсюда и название: когда-то шахтёры брали под землю канареек, которые раньше людей реагировали на ядовитый газ и предупреждали об опасности.

Вот как это работает: вы следите за ошибками и другими показателями новой версии и, если всё в порядке, постепенно увеличиваете долю трафика. Размер каждого шага зависит от нагрузки и характера изменения. Для сервиса с несколькими запросами в минуту нужна одна схема наблюдения, а для компонента с постоянным потоком запросов — другая.

Решите заранее, как пользователи будут распределяться между версиями. Для сервиса без сохранения состояния можно направлять отдельные запросы случайным образом. Если сервис хранит данные пользовательской сессии — например, авторизацию, содержимое корзины или черновик заказа, то пользователей лучше распределять по идентификатору, аккаунту, устройству или региону. Так, начав работу с одной версией, клиент продолжит работать с ней до конца сессии.

Когда распределение настроено, остаётся понять, сколько за новой версией наблюдать. Пять минут при паре запросов ничего не покажут, а на стабильных показателях каждый следующий день наблюдения всё менее информативен. Определите заранее оба порога: сколько операций нужно для доверия метрикам и когда наблюдение пора прекращать.

Дальше процесс можно автоматизировать: контроллер поэтапной доставки получает метрики, сравнивает их с заданными условиями и выбирает следующий шаг — увеличить трафик, остановить выкладку или выполнить откат. При этом все условия хранятся рядом с конфигурацией релиза.

Статус контейнера Running подтверждает только запуск процесса. Для решения о продолжении выкладки нужны сигналы нескольких уровней.

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

Для критичных операций одной агрегированной метрики недостаточно. Общая доля ошибок может выглядеть нормально, хотя конкретный регион, тип клиента или способ оплаты уже сломан. Поэтому перед выкладкой определите разрезы, в которых будете анализировать результат.

Feature flag позволяет изменить поведение приложения без новой выкладки кода. С его помощью вы можете открыть функцию внутренним пользователям, заданному сегменту или небольшой доле аудитории. При проблеме флаг работает как kill switch — оперативный выключатель функции.

Флаг не заменяет канареечную выкладку контейнера. Эти механизмы контролируют разные уровни:

• канареечная выкладка проверяет новую версию приложения и её взаимодействие с инфраструктурой;
• feature flag управляет отдельным пользовательским сценарием внутри уже развёрнутой версии.

Вместе они позволяют сначала проверить техническую стабильность сборки, а затем постепенно открыть новое поведение.

Флаги тоже требуют контроля: для временного переключателя заранее определите владельца, назначение и дату удаления. Доступ к прод-флагам лучше ограничить, а изменения записывать в журнал с указанием пользователя, времени и причины.

Ещё один важный момент: приложение должно предсказуемо работать при недоступности сервиса флагов. Для критичных функций вы заранее задаёте безопасное значение по умолчанию и срок, в течение которого клиент может использовать закешированную конфигурацию.

Откат контейнерного образа возможен, пока старая и новая версии совместимы с одной схемой данных. После удаления колонки, изменения формата события или необратимого преобразования записей старый код может перестать работать.

Для изменений, затрагивающих схему данных, применяют подход expand–migrate–contract:

1. Сначала вы расширяете модель данных: добавляете новую колонку, таблицу или поле события, сохраняя старую структуру.
2. Затем выкатываете код, который понимает оба формата. При необходимости сервис некоторое время пишет данные одновременно в старое и новое представление.
3. После миграции чтение переключается на новый формат, а вы проверяете результат на прод-нагрузке.
4. Старую структуру удаляют отдельным релизом, когда предыдущая версия приложения больше не понадобится для отката.

Да, эта последовательность увеличивает число этапов, зато сохраняет совместимость между версиями. Для API и очередей действует тот же принцип: потребители должны уметь обрабатывать новые поля, а производитель — учитывать время обновления зависимых сервисов.

В распределённой системе разные версии компонентов некоторое время работают одновременно, поэтому совместимость становится частью самого релизного процесса.

У RWB похожая задача решена через правила совместимости — рассказали об этом в кейсе о переходе к микрофронтендам. Основное приложение выбирает подходящую версию независимо развёртываемого фронтенд-модуля. Благодаря этому вы можете выпускать изменения постепенно и при необходимости откатывать отдельный микрофронтенд.

В рабочий сценарий нужно включить:

• где хранится последний проверенный артефакт;
• кто или какая автоматика запускает возврат;
• сохраняет ли старая версия совместимость с текущими данными и конфигурацией;
• сколько времени проходит от сигнала до восстановления пользовательского сценария;
• как вы убеждаетесь, что откат действительно завершился успешно.

Проверьте эту процедуру заранее на тестовой среде. При этом сценарий должен совпадать с прод-процессом. Если вы впервые выполняете откат во время реального инцидента, часть времени уйдёт на выяснение того, как именно он должен работать.

Проблему можно исправлять новой версией, если миграция уже изменила большой объём данных и предыдущий код больше не поддерживает новый формат. Поэтому сценарий отката нужно учитывать ещё до начала миграции: определить условия, при которых возврат к старой версии уже невозможен, назначить ответственных и описать последовательность восстановления в runbook — пошаговой инструкции для дежурных инженеров.

Для первой управляемой выкладки не обязательно сразу строить сложную платформу поэтапной доставки. Базовый процесс можно собрать из нескольких понятных правил:

• прод получает тот же артефакт, который прошёл проверки;
• релиз начинается с ограниченного трафика или аудитории;
• метрики имеют заранее определённые условия остановки.

Когда вам уже понятен процесс, можно автоматизировать продвижение между этапами, сравнение метрик и откат. Автоматизация в этом случае ускоряет готовый процесс и снижает количество ручных действий.

Безопасность релиза определяется возможностью остановиться. Технически её обеспечивают четыре рычага: какой артефакт вы разворачиваете, какая доля пользователей его видит, по каким сигналам останавливаете выкладку и сколько времени занимает откат. Для старта достаточно минимума: единый артефакт, ограниченный первый этап, измеримые критерии остановки и отрепетированный откат.