Процес затвердження релізів
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) Класи змін та шляхи узгодження
Підвищення класу - при перетині меж ризику (платежі, 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 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→prod), 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, захищає виручку і комплаєнс і дозволяє командам випускати цінність часто і безпечно.