Новая версия складской системы установилась без ошибок. Через несколько минут выяснилось, что часть накладных печатается неправильно. Команда возвращает трафик на старые серверы, но они уже не понимают новый статус отгрузки. Кнопка возврата сработала, склад к работе не вернулся.
Blue-Green Deployment полезен тем, что позволяет подготовить новую версию отдельно от работающей и быстро сменить обслуживающую среду. Возможность вернуться зависит от большего числа условий. Разбирать их лучше до выпуска, пока предыдущая версия ещё действительно может выполнять нужные операции.
Две среды разделяют подготовку и переключение
Пусть Blue обслуживает пользователей, а Green готовится принять новую версию. Это два различимых набора приложения и его настроек. Названия не обозначают постоянных ролей: при следующем выпуске они могут поменяться.
Green можно запустить, проверить и прогреть, не заменяя работающий Blue. После проверки маршрутизацию переводят на Green. В исходном описании подхода главное именно такое разделение этапов. Ни количество баз, ни способ переключения не определяются цветами автоматически.
Новая среда должна быть сопоставима с рабочей там, где это влияет на результат: разрешения, сертификаты, подключения, лимиты и доступ к партнёрам. При этом тестовые операции надо отделить от реальных. Проверка печати в Green не должна отправить настоящую накладную перевозчику или повторно зарезервировать товар.
Полезна отдельная проверка ёмкости. Среда, успешно обслужившая несколько тестовых обращений, ещё не доказала готовность принять весь поток. А большой прогрев данных через общую базу может повлиять на Blue ещё до переключения пользователей.
Проведите границу среды через схему данных
Частый вариант — две версии приложения обращаются к одному хранилищу. Тогда актуальные данные не нужно переносить при каждом переключении. Но обе версии должны понимать структуру и смысл записей, которые могут встретиться в период совместной работы.
Например, добавление нового необязательного поля иногда совместимо со старой программой. Удаление поля, на которое она рассчитывает, — уже нет. Новое значение статуса тоже может нарушить работу, хотя таблицы вообще не изменились. Проверять только успешное выполнение миграции недостаточно: нужно выполнить старым кодом операции с данными, записанными новым.
Обычно изменения разделяют: сначала подготовить совместимое расширение, затем перевести приложение, а устаревшую часть удалить после завершения перехода. Такой порядок обсуждается в рекомендациях AWS по данным при Blue-Green. Он не гарантирует отсутствия блокировок или других последствий самой миграции.
Если у сред отдельные базы, задача становится другой. Нужно обеспечить актуальность Green перед переключением, а для возврата — определить судьбу записей, созданных после него. Простой перевод адреса обратно к старой копии может потерять подтверждённые изменения. Отдельные хранилища требуют собственного плана синхронизации, а не только двух подключений в конфигурации.
Пользовательские запросы — не весь трафик
После изменения маршрута часть соединений и начатых операций может оставаться в Blue. Старый экземпляр нельзя безоговорочно выключить в ту же секунду. Ему дают завершить согласованную работу либо сохраняют состояние для безопасного продолжения. Распространение сетевой конфигурации также занимает время; это отдельно учитывает, например, реализация Blue-Green в Argo Rollouts.
Со складом особенно важно проверить фоновые задания. Если обе среды запустят ежедневное формирование документов, дубли появятся независимо от того, куда направлены пользователи. Для расписаний и потребителей очереди нужен явный порядок передачи работы, защита от повторного эффекта и понимание совместимости сообщений.
Есть и обратные вызовы партнёров. Перевозчик может прислать подтверждение по адресу, сохранённому до выпуска. Смена основного маршрута сама по себе не обновляет чужую интеграцию. Незавершённые операции, сессии сотрудников и временные файлы должны иметь понятную судьбу.
У возврата есть срок и условия
Держать Blue включённым недостаточно. Пока Green работает, меняются данные, учётные данные и состояние внешних процессов. В какой-то момент старый код перестанет быть безопасным вариантом, даже если его серверы исправны.
Поэтому перед выпуском указывают условия возврата: какие изменения допустимы, кто принимает решение, что проверяют после переключения назад. При неисправности нового формата накладной нужно не только восстановить программу, но и найти уже созданные документы. Повторная печать не должна автоматически означать повторную отгрузку.
Возврат приложения, исправление записей и компенсация внешних действий — отдельные процедуры. Иногда безопаснее выпустить исправление вперёд, временно ограничив функцию, чем возвращать старую версию к данным, которых она не понимает. Это решение нельзя принимать по одному сигналу «у Green выросли ошибки».
Когда вторую среду можно освободить
После переключения наблюдают не только ошибки HTTP. Для склада важны завершённые отгрузки, читаемые накладные, обработка подтверждений и отсутствие дубликатов. Проверка готовности процесса может быть зелёной при неверном результате этих операций.
Период наблюдения выбирают по тому, когда проявляются риски изменения. Если оно затрагивает вечернее задание, несколько спокойных минут дневного трафика его не проверят. Нужно сохранить подходящий способ возврата или провести отдельную проверку задания до завершения окна отката.
Цена Blue-Green включает дополнительную мощность на согласованный период, сравнение конфигураций и обслуживание двух версий. Не вся инфраструктура обязана дублироваться целиком; общая часть при этом остаётся общей причиной отказа. Для простого сервиса последовательное обновление с хорошим восстановлением может оказаться дешевле. Для ограничения первоначальной аудитории можно сочетать подготовку второй среды с Canary.
В плане выпуска стоит оставить конкретную контрольную точку: до какого изменения возврат в Blue ещё проверен и что делать после неё. Затем на тестовом рабочем сценарии пройти переключение и возврат с созданной накладной и незавершённым заданием. Так становится видно, чем компания действительно располагает: запасной работающей версией или только запасными серверами.