Процесс утверждения релизов

1) Цель и зона ответственности

Процесс утверждения релизов обеспечивает предсказуемые и безопасные изменения платформы без нарушения SLO, выручки и комплаенса. Он охватывает весь путь: от pull request до полного промоута в прод и пост-мониторинга.

2) Принципы

1. SLO-first: релиз разрешен только при зеленых SLI/без burn-rate.
2. Малые партии и обратимость: канареечная/прогрессивная доставка, быстрый rollback.
3. Policy-as-Code: гейты, SoD, freeze-окна и риск-классы — верифицируются автоматически.
4. Единый источник правды: артефакты/конфиги/флаги — в Git, среда приводится GitOps-реконсайлером.
5. Аудит и доказуемость: WORM-журналы, след принятия решений, четкие владельцы.
6. Безопасность по умолчанию: секреты отдельно, минимальные привилегии, гео-гейты.
7. Коммуникации без сюрпризов: подготовленные шаблоны для внутренних/внешних обновлений.

3) Роли и RACI

Release Manager (RM) — владелец конвейера, календарь, гейты. A/R

Service Owner (SO) — владелец домена, принимает риск, готовит артефакты. A/R

SRE/Platform — SLO-гейты, раскатки, авто-откаты. R

QA Lead — стратегия проверок, результаты тестов. R

Security/Compliance — сканы, SoD, регуляторика. C/A

CAB (Change Advisory Board) — решение по Normal-классу. A

On-call IC/CL — готовность к инциденту и коммуникациям. R/C

Stakeholders (Biz/Support/Partners) — информирование. I

4) Классы изменений и пути согласования

Класс	Примеры	Путь согласования	Сроки
Standard	Безопасные, шаблонные (док-репорты, неинвазивные конфиги)	Авто-гейты + пост-уведомление	Часы
Normal	Новые фичи, схемы БД с миграцией, изменения роутинга PSP	Гейты + CAB + прогрессивная доставка	1–3 дня
Emergency	Горячие фиксы P1, отключение опасной фичи/экспорта PII	IC/RM решение + пост-фактум CAB	Минуты–часы

Повышение класса — при пересечении границ риска (платежи, RG, PII, лимиты).

5) Конвейер релиза и гейты (сквозной поток)

Этап 0. Планирование и календарь

Freeze-окна (праздники/матчи), слот он-колла и CL, готовность шаблонов статуса.

Этап 1. PR → Build

Линтеры/лицензии, SBOM, unit/contract tests, секрет-скан.

Этап 2. Интеграция/Безопасность

E2E (виртуализированные провайдеры PSP/KYC), SAST/DAST, dependency review.

Этап 3. Staging / Репетиция

Паритет с продом, миграции с обратимостью, фичефлаги на 5–25%, чек-лист “release drill”.

Гейт А — Качество и безопасность (обязателен)

+ все тесты/сканы зеленые

+ схемы/конфиги валидны, нет “красных” SLI staging

+ SoD/4-eyes для high-risk изменений

Этап 4. Пред-прод (канареечная доставка)

1–5% трафика по сегментам (tenant/geo/банк), runtime-валидаторы, guardrails.

Гейт B — SLO/бизнес-гейт

+ нет деградаций SLO/KRI (латентность/ошибки/оплата)

+ нет SRM/аномалий в метриках экспериментов

+ Comms готов: черновик статуса/партнеров

Этап 5. Рамп-ап → 25% → 100% (регион/тенант)

Пошаговый промоут с таймерами пост-мониторинга.

Этап 6. Пост-мониторинг (30–60 мин)

Дашборд релиза, burn-rate, жалобы/тикеты, авто-закрытие/rollback при нарушениях.

6) Автоматизированные решения (policy-engine)

Псевдо-правила:

SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
PII-export: `require dual_control if config.affects == "PII_EXPORT"`
Freeze: `deny deploy if calendar.freeze && not emergency`
Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`

7) Артефакты релиза

Release Manifest (обязателен): цель, риск-класс, области (tenant/region), флаги, миграции, план раскатки, план отката, владелец, контакты он-колла.
Evidence Pack: результаты тестов/сканов, скриншоты дашбордов staging, dry-run миграций.
Comms Kit: шаблоны статуса (внутренний/внешний/партнеры), ETA/ETR.
Backout Plan: точные шаги отката и критерии, при которых он срабатывает.

Пример (выжимка YAML):

yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"

8) Канареечные/Blue-Green/Feature-Flag раскатки

Canary — безопасный дефолт: малый охват, сегментация по GEO/tenant/BIN.
Blue-Green — для тяжелых изменений: переключение маршрута, быстрый откат.
Флаги — для поведенческих фич: TTL, kill-switch, guardrails, SoD.

9) Управление конфигами и секретами

Конфиги как данные, схемы и валидаторы; GitOps-промоут с drift-детектором.
Секреты — в KMS/Secret Manager, доступ JIT, аудит и маскирование.

10) Коммуникации и статус-страницы

Внутренние: вар-рум/чат, оповещение он-коллов, шаблоны апдейтов.
Внешние: публикации только через CL, заранее подготовленные черновики.
Партнеры (PSP/KYC/студии): targeted-уведомления при затрагивании интеграций.
Статус: релиз не является инцидентом, но имеет окно наблюдения с метриками.

11) Экстренные релизы (Emergency)

Триггеры: P1-деградация, уязвимость, риски PII/RG.
Путь: решение IC+RM → минимальный набор гейтов (линтер/сборка) → canary 1–2% → мониторинг → промоут.
Обязательно: пост-фактум CAB, пост-мортем ≤ D+5, документирование компромиссов.

12) Аудит, SoD и соответствие

SoD/4-eyes: изменения PSP-роутинга, лимитов бонусов, экспортов данных.
WORM-журнал: кто/что/когда/зачем; версии политик; дифф релиза/флагов/конфигов.
Geo/Privacy: данные и логи в нужной юрисдикции; отсутствие PII в артефактах.

13) Наблюдаемость и пост-контроль

Дашборд релиза: SLI (auth-success, bet→settle p99), error-rate, жалобы, конверсия, лаги очередей.
Алерты: burn-rate, SRM, рост 5xx, деградация PSP по банкам/GEO.
Отчеты: CFR, MTTR релиз-инцидентов, среднее время пост-мониторинга, auto-rollback rate.

14) KPI/KRI процесса

Lead Time for Change (PR→прод), Change Failure Rate, MTTR релиз-инцидентов.
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
Coverage of Release Drill (стейджинг-репетиции), SoD violations (цель — 0).
Comms SLA (наличие черновиков, соблюдение таймингов).

15) Дорожная карта внедрения (6–10 недель)

Нед. 1–2: определить классы изменений, гейты и артефакты; включить линтеры, SBOM, секрет-скан; календарь релизов и freeze.
Нед. 3–4: GitOps для конфигов, canary/blue-green, SLO-гейты, шаблоны Comms и вар-рум.
Нед. 5–6: policy-engine (SoD/4-eyes, risk-rules), авто-rollback по метрикам; дашборд релизов.
Нед. 7–8: репетиции (staging drills), интеграция с фичефлагами/инцидент-ботом, отчеты KPI/KRI.
Нед. 9–10: аудит WORM, DR-учения релизов, оптимизация CFR, обучение ролей (RM/SO/CL/IC).

16) Антипаттерны

Релизы без обратимости и canary → массовые инциденты.
Игнор SLO-гейтов “ради дедлайна”.
Конфиги/флаги без схем и TTL → “застывшие” состояния.
Ручные клики в проде без Git/аудита.
Публичные апдейты без роли CL и шаблонов.
Секреты в репозитории; доступы без JIT и журналирования.
CAB как тормоз без данных: решения должны подкрепляться метриками релиза.

Итог

Процесс утверждения релизов — это инженерный и управленческий каркас, который соединяет качество, безопасность и скорость: политики как код, SLO-гейты, прогрессивная доставка, прозрачные коммуникации и доказуемый аудит. Такой подход снижает CFR и MTTR, защищает выручку и комплаенс и позволяет командам выпускать ценность часто и безопасно.