Стратегия развёртывания¶

Требования применяются к production-развёртываниям. Уровни обязательности определены в корневом README.md.

DEP-ROL-001. Поэтапная замена экземпляров¶

Уровень: MUST

Применяется к: развёртыванию новой версии сервиса

Экземпляры должны заменяться поэтапно с сохранением минимальной доступной ёмкости. Новая версия не должна получать трафик до успешной readiness. Параметры surge, unavailable и timeout должны быть численно определены проектом и согласованы с нагрузочной моделью.

Обоснование¶

Поэтапная замена ограничивает область дефекта и сохраняет доступность.

Проверка¶

тест rolling deployment под нагрузкой;
проверка readiness gate и доступной ёмкости;
тест зависшего старта.

Исключения¶

Сервис с согласованным окном недоступности требует ADR.

DEP-ROL-002. Совместимость соседних версий¶

Уровень: MUST

Применяется к: периоду одновременной работы старой и новой версии

Версии должны совместно работать с API, событиями и схемой данных по BE-COMP-001, INT-EVT-002 и BE-MIG-001. Развёртывание не должно требовать одновременного переключения всех экземпляров или потребителей.

Обоснование¶

Rolling deployment неизбежно создаёт период смешанных версий.

Проверка¶

integration-тест матрицы соседних версий;
contract и schema compatibility checks;
тест смешанного трафика.

Исключения¶

Несовместимое переключение требует отдельной версии и ADR с планом миграции.

DEP-ROL-003. Критерии продвижения¶

Уровень: MUST

Применяется к: переходу между этапами deployment

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

Для изменения пользовательского поведения должен проверяться связанный бизнес-результат либо другой наблюдаемый показатель корректности, который health и технические сигналы не подтверждают. Превышение порога должно останавливать rollout и запускать заранее выбранный rollback или roll-forward по DEP-ROL-004.

Ручное продвижение MAY использоваться при недостаточном объёме данных, если уполномоченный владелец проверяет заранее определённый минимальный набор сигналов и решение сохраняется в GitLab.

Обоснование¶

Факт запуска процесса не доказывает безопасность версии.

Проверка¶

тест нарушения каждого gate;
проверка запросов и окна наблюдения;
тест отсутствующей телеметрии;
контролируемая регрессия бизнес-результата;
тест остановки и выбранного recovery action.

Исключения¶

Не применяются.

DEP-ROL-004. Проверяемый rollback¶

Уровень: MUST

Применяется к: каждой production-поставке

До поставки должен существовать проверенный способ вернуть предыдущий артефакт и совместимую конфигурацию либо выполнить заранее определённый roll-forward. Критерии выбора действия должны быть зафиксированы. Автоматический rollback MAY использоваться, но не является обязательным.

Если изменение данных необратимо для старой версии, rollback приложения запрещён до выполнения совместимого плана данных.

Обоснование¶

Rollback без учёта данных способен усилить инцидент.

Проверка¶

rehearsal rollback;
тест критерия выбора rollback или roll-forward;
review совместимости schema и конфигурации.

Исключения¶

Roll-forward допустим вместо rollback, если указаны исполнимая процедура и временной бюджет восстановления.

DEP-ROL-005. Завершение старых экземпляров¶

Уровень: MUST

Применяется к: удалению экземпляра во время deployment

Среда должна соблюдать BE-SHUT-001–BE-SHUT-007 и BE-HLTH-005. Termination grace period должен превышать общий shutdown timeout и интервал удаления из маршрутизации.

Обоснование¶

Принудительная остановка создаёт ошибки и повторную обработку.

Проверка¶

deployment-тест с долгой операцией;
измерение порядка readiness и shutdown;
проверка отсутствия принудительного kill в штатном сценарии.

Исключения¶

Не допускаются для штатного deployment.