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

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

В этом документе:

canary — новая версия, получающая ограниченную часть production-трафика или работы одновременно с baseline-версией;
canary cohort — однозначно определённое множество операций, субъектов или единиц работы, назначенных canary-версии;
blue/green — две полные revision приложения, между которыми переключается production-маршрут.

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.

DEP-ROL-006. Ограниченный canary cohort¶

Уровень: MUST

Применяется к: production canary-развёртыванию

До запуска проект должен определить последовательность этапов, максимальную долю трафика или работы на каждом этапе, правило включения в canary cohort и максимальную область отказа. Назначение одного субъекта должно оставаться стабильным в пределах контрактного периода, если смена версии между операциями может изменить результат.

Правило должно отдельно определять long-lived connections, фоновые операции и работу без пользовательского запроса. Трафик или работа, не назначенные canary cohort, должны оставаться на baseline-версии. Telemetry должна различать baseline и canary по фактическому service.version и cohort.

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

Процент экземпляров не определяет фактическую долю риска при sticky sessions, долгих соединениях или неравномерной фоновой работе.

Проверка¶

тест распределения на каждой границе доли;
тест стабильности cohort между запросами и экземплярами;
проверка long-lived connection и фоновой операции;
сверка telemetry с фактическими service.version и cohort.

Исключения¶

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

DEP-ROL-007. Продвижение и остановка canary¶

Уровень: MUST

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

На каждом этапе критерии DEP-ROL-003 должны вычисляться отдельно для canary cohort и baseline. Используемые запросы telemetry и результаты gate должны различать фактические service.version и cohort; общий агрегат нескольких версий или cohort не должен считаться evidence безопасности canary.

Для каждого этапа должно быть заранее выбрано действие: возврат cohort на baseline, остановка новой работы либо roll-forward. Запись данных и внешний эффект canary должны оставаться совместимыми с выбранным действием и DEP-ROL-002; возврат маршрута не должен объявляться восстановлением, если необратимый эффект требует отдельной компенсации.

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

Общая telemetry скрывает малую дефектную cohort, а возврат трафика не отменяет уже выполненные изменения данных.

Проверка¶

контролируемая регрессия только в canary cohort;
сверка раздельных запросов и результатов для canary cohort и baseline;
rehearsal остановки и выбранного recovery action после записи данных;
проверка блокировки следующего этапа.

Исключения¶

Ручное решение допускается только по условиям DEP-ROL-003.

DEP-ROL-008. Переключение blue/green¶

Уровень: MUST

Применяется к: production blue/green-развёртыванию

Blue и green revisions должны до переключения одновременно проходить readiness и работать с совместимыми API, событиями, конфигурацией и данными. Проект должен определить ограниченное время переключения маршрута, обработку sessions, long-lived connections и фоновой работы, а также критерии успеха и возврата.

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

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

Мгновенное переключение route не делает совместимыми данные, фоновые writers или долгие соединения и не гарантирует исполнимый возврат.

Проверка¶

rehearsal переключения и возврата под нагрузкой;
тест session, long-lived connection и фоновой операции;
конкурентный тест write path обеих revisions;
проверка готовности предыдущей revision в течение rollback-окна и её удаления после завершения.

Исключения¶

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