Blue-green deployment переключает трафик слишком рано: как настроить readiness

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

Разделите startup, liveness и readiness. Переключайте production-трафик только после функционального smoke test на green, прогрева критичных зависимостей и проверки совместимости базы. Сохраняйте возможность быстро вернуть маршрут на blue.

Что проверить в первую очередь

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

• Проверьте, какое условие pipeline считает готовностью green.
• Сравните время открытия порта и время успешного бизнес-запроса.
• Уточните порядок миграций БД, прогрева кеша и регистрации consumers.
• Посмотрите ошибки именно первых минут после переключения.

Почему возникает проблема

Внешний симптом часто появляется не в том компоненте, где возникла первичная ошибка. Интерфейс может показывать неверное состояние из-за backend, очереди, кеша, прав доступа или внешнего API. Полезно проследить данные от источника до результата и найти первую точку расхождения. Это надежнее, чем исправлять последнее сообщение об ошибке или бесконечно перезапускать сервис.

• Health endpoint всегда возвращает 200, проверяя только процесс.
• Балансировщик использует TCP check вместо readiness URL.
• Smoke test запускается до применения конфигурации или secrets.
• Миграция несовместима со старой blue-версией.
• После переключения autoscaling и connection pools еще не прогреты.

Пошаговая диагностика

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

• Запишите timeline: deploy, start, readiness, smoke, switch и первые ошибки.
• Выполните через green endpoint реальные чтение и безопасную запись.
• Проверьте зависимости readiness по отдельности и их timeout.
• Сравните schema compatibility для blue и green во время совместной работы.
• Измерьте latency и error rate до, во время и после switch.

Что должна подтверждать readiness-проверка

Readiness отвечает на вопрос, можно ли этому экземпляру прямо сейчас отдавать пользовательский трафик. Она не должна скрывать критичную зависимость и не должна падать из-за необязательной фоновой функции.

• Приложение загрузило конфигурацию и обязательные секреты.
• Есть рабочее соединение с критичной БД и совместимая schema.
• Основные маршруты выполняют минимальный smoke-сценарий.
• Экземпляр завершил startup/warm-up и способен выдержать начальную нагрузку.
• При снятии readiness балансировщик прекращает новые запросы, но дает завершить текущие.

Как исправить проблему

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

• Создайте отдельные startup, readiness и liveness endpoints с разной семантикой.
• Добавьте pre-switch smoke tests через прямой адрес green.
• Используйте expand-contract миграции, совместимые с обеими версиями.
• Прогревайте кеш и connection pools до включения полного трафика.
• Настройте автоматический rollback по error rate и latency с понятным окном наблюдения.

Безопасный порядок внедрения

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

Как проверить результат

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

• Green не получает production-трафик до успешного функционального smoke test.
• Blue продолжает работать с БД после миграции до завершения переключения.
• Искусственная ошибка readiness снимает экземпляр с маршрута без обрыва активных запросов.
• Rollback возвращает трафик без ручной правки DNS и потери состояния.

Типичные ошибки при исправлении

• Делать health endpoint без проверки критичных зависимостей.
• Удалять blue сразу после первого успешного запроса.
• Выполнять необратимую миграцию до проверки новой версии.
• Считать отсутствие 5xx достаточным без контроля latency и бизнес-метрик.

Как предотвратить повторение

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

• Автоматизируйте timeline и метрики каждого deployment.
• Тестируйте rollback и совместимость миграций заранее.
• Используйте небольшой canary-трафик перед полным switch при высоком риске.
• Документируйте критерии готовности и остановки релиза.

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Чем readiness отличается от liveness?

Readiness управляет получением трафика, liveness решает, нужно ли перезапустить процесс. Смешивание приводит к лишним рестартам или ранней маршрутизации.

Нужен ли blue-green при одной базе?

Можно использовать одну базу, если миграции совместимы одновременно со старой и новой версией.

Когда нужна помощь специалиста

Если blue-green релиз отдает трафик неготовой версии, я могу разобрать pipeline, probes, миграции и балансировщик, добавить smoke tests, прогрев и автоматический rollback.