Стратегия развёртывания и отката¶
Требования применяются к выполнению deployment, продвижения, rollback и
фиксации результата в non-production и production целях. Уровни
обязательности определены в корневом README.md.
INF-REL-001. План поставки¶
Уровень: MUST
Применяется к: production release
До запуска должны быть определены release identifier image, изменение конфигурации,
миграции, критерии успеха, наблюдаемое окно и выбранное действие при отказе.
Критерии и действия должны реализовывать применимые
architecture:DEP-ROL-001–DEP-ROL-008, а не задавать новую семантику
готовности приложения.
Обоснование¶
Факт запуска workload не доказывает корректность версии.
Проверка¶
- review GitLab deployment metadata;
- тест нарушения каждого release gate.
Исключения¶
Не допускаются.
INF-REL-002. Rolling update Kubernetes¶
Уровень: MUST
Применяется к: Kubernetes Deployment в профиле high-availability
Стратегия должна сохранять как минимум один готовый экземпляр и достаточную
ёмкость во время замены. maxUnavailable, maxSurge, readiness и progress
deadline должны иметь явные значения, вычисленные для числа реплик и
architecture:DEP-ROL-001. Неуспешный progress deadline должен завершать job с
ошибкой и останавливать дальнейшее продвижение.
Обоснование¶
Настройки по умолчанию могут не соответствовать числу реплик и ёмкости.
Проверка¶
- rollout под нагрузкой;
- тест зависшего запуска и недостаточной ёмкости.
Исключения¶
Stateful workload MAY использовать другую поэтапную стратегию с тем же проверяемым результатом.
INF-REL-003. Single-instance deployment¶
Уровень: MUST
Применяется к: production-цели single-instance
Владелец должен явно определить ожидаемое окно недоступности при deployment и восстановлении узла. Pipeline должен исключать одновременный запуск двух экземпляров, если приложение не поддерживает конкурентную работу.
Обоснование¶
Single-instance — осознанный профиль, а не неявное обещание доступности.
Проверка¶
- сопоставление runbook и SLO;
- тест повторного запуска и блокировки второго экземпляра.
Исключения¶
Не допускаются.
INF-REL-004. Проверяемый rollback или roll-forward¶
Уровень: MUST
Применяется к: каждой production-поставке
Deployment automation должна исполнять выбранный проектом rollback или
roll-forward по architecture:DEP-ROL-004 с сохранёнными release identifier
image и commit конфигурации. Допустимость возврата версии данных должна браться из
architecture:BE-MIG-001–BE-MIG-004; инфраструктурный сценарий не должен
вводить собственное правило совместимости.
Обоснование¶
Непроверенный rollback способен усилить инцидент и повредить данные.
Проверка¶
- rehearsal в non-production;
- проверка совместимости схемы и конфигурации.
Исключения¶
Roll-forward допустим вместо rollback при указанном бюджете восстановления.
INF-REL-005. Фиксация результата¶
Уровень: MUST
Применяется к: завершившемуся production deployment
GitLab environment или GitOps status должен сохранять цель, release identifier image, commit конфигурации, pipeline, время, исполнителя и результат. Неуспешный deployment не должен отмечаться как поставленная версия.
Обоснование¶
Операционный аудит требует точного ответа, что и когда работает.
Проверка¶
- сверка runtime image с GitLab/GitOps записью;
- тест неуспешного rollout.
Исключения¶
Не допускаются.
INF-REL-006. Порядок конфигурации, секрета и приложения¶
Уровень: MUST
Применяется к: release, изменяющему более одного из image, ConfigMap, Secret, schema данных или route
План должен определять совместимый порядок изменения и точку, после которой
rollback старой версии запрещён. Старый и новый экземпляры должны получать
совместимые значения во время смешанной работы по
architecture:DEP-ROL-002. Удаление старого значения или route допускается
только после отсутствия его потребителей.
Обоснование¶
Независимо корректные изменения могут быть несовместимы при другом порядке.
Проверка¶
- тест каждой промежуточной стадии со смешанными версиями;
- rollback до и после точки необратимости.
Исключения¶
Атомарная single-instance поставка MAY не иметь смешанных версий, но должна соблюдать заявленное окно недоступности.
INF-REL-007. Compose release¶
Уровень: MUST
Применяется к: удалённой Docker Compose-цели
Pipeline должен сначала получить и проверить все новые release images, затем
выполнить ограниченное по времени compose up или эквивалент, дождаться
healthchecks и сверить работающие release identifiers. При ошибке старые работоспособные
containers не должны удаляться до запуска rollback либо явного объявления
недоступности.
Обоснование¶
Последовательный pull после остановки создаёт лишнее окно недоступности и необратимое частичное состояние.
Проверка¶
- недоступный Registry и ошибочный healthcheck;
- сверка container image после успешного и неуспешного deployment.
Исключения¶
Остановка до запуска допустима, если этого требует single-writer приложение и окно зафиксировано.
INF-REL-008. Очистка старых revisions¶
Уровень: MUST
Применяется к: завершённому release
История ReplicaSet, Helm release, Compose containers и deployment artifacts
должна иметь численный retention. Очистка не должна удалять revision,
необходимую для действующего rollback, расследования или аудита по
INF-ART-005.
Обоснование¶
Неограниченная история расходует ресурсы, а преждевременная очистка ломает восстановление.
Проверка¶
- проверка retention после нескольких releases;
- rehearsal rollback к самой старой сохраняемой revision.
Исключения¶
Не допускаются.
INF-REL-009. Маршрутизация и evidence canary¶
Уровень: MUST
Применяется к: инфраструктурной реализации production canary по
architecture:DEP-ROL-006 и architecture:DEP-ROL-007
Delivery и runtime-конфигурация должны материализовать отдельные baseline и
canary revisions, закрытые доли либо правила маршрутизации и стабильный
признак cohort, требуемый приложением. Фактическая revision должна передавать
свой service.version в telemetry независимо от route label.
Pipeline должен сохранять для каждого этапа заданную долю, фактический интервал, использованные запросы telemetry, численные результаты gate и решение о продвижении или остановке. Он должен уметь прекратить назначение новой работы canary и вернуть поддерживаемый трафик на baseline без изменения непроверенного артефакта.
Обоснование¶
Без воспроизводимой маршрутизации и evidence невозможно доказать фактическую область canary или причину его продвижения.
Проверка¶
- запрос фактических revisions, routes и долей на каждом этапе;
- сверка
service.version, cohort и выбранной revision в telemetry; - контролируемый отказ gate и возврат маршрутизации;
- проверка сохранённого stage evidence в GitLab или GitOps status.
Исключения¶
Canary фонового consumer MAY разделять работу средствами broker вместо сетевого route, если assignment, доля, остановка новой работы и evidence реализуют тот же архитектурный контракт.
INF-REL-010. Жизненный цикл blue/green revisions¶
Уровень: MUST
Применяется к: инфраструктурной реализации production blue/green по
architecture:DEP-ROL-008
Delivery должна создавать различимые blue и green revisions с отдельными release identifiers и проверяемым production-route. До переключения pipeline должен подтвердить readiness целевой revision и совместимость требуемой конфигурации, routes и миграционного состояния.
Переключение и возврат route должны быть автоматизированы и ограничены по
времени. Предыдущая revision и необходимая ей ёмкость должны сохраняться до
конца архитектурного rollback-окна. После окна automation должна подтвердить
отсутствие трафика и незавершённой работы, удалить revision по retention
INF-REL-008 и исключить одновременный write path, не разрешённый приложением.
Обоснование¶
Две revision без управляемого route и жизненного цикла создают не blue/green, а неопределённое конкурентное production-состояние.
Проверка¶
- rehearsal switch и revert с измерением времени;
- запрос release identifiers, route и ёмкости обеих revisions;
- тест запрета конкурирующего write path;
- проверка cleanup только после rollback-окна и отсутствия работы.
Исключения¶
Удаление предыдущей revision до окончания окна допускается только при
архитектурном запрете rollback и исполнимом roll-forward по
architecture:DEP-ROL-004.