Автоматичний відкат релізів

1) Навіщо потрібен авто-відкат

• знижує CFR і MTTR;
• захищає SLO (auth-success, p99 «stavka→settl», error-rate);
• запобігає комплаєнс-інцидентам (PII/RG/AML).

2) Принципи

1. Revert is a feature: відкат планується при дизайні релізу.
2. Policy-as-Code: пороги, вікна, винятки - валідація в конвеєрі.
3. Canary-first: промоут по сходах, відкат - дзеркально ступенях.
4. Data-safe: міграції оборотні/сумативні; конфіги - версіоновані.
5. SLO-gates: червоні SLI/guardrails → негайний авто-відкат.
6. Explainability: таймлайн, диффи, причини - в журнал WORM.
7. No single button of doom: обмеження, підтвердження на ризик-дії, SoD.

3) Тригери авто-відкату (сигнали)

3. 1 Технічні SLI/KRI

auth_success_rate drop по GEO/PSP/BIN (наприклад, −10% в TR ≥10 хв).
latency p99/error-rate ключових шляхів (депозит/виведення/сеттл).
queue lag / DLQ rate / retry storm.
db replication lag / cache miss surge.

3. 2 Бізнес-сигнали

deposit_conversion −X п. п. на канарі проти контролю.
settle throughput падіння відносно базової лінії.
chargeback/decline spikes (soft/hard).

3. 3 Критичні події

Провал SRM в активному A/B (спотворення трафіку).
Спрацьовування security/PII guardrail.
Несумісність схем/конфігів (валідатор/лінтер).

4) Архітектурні шаблони оборотності

Canary → Ramp → Full: промоут по 5%→25%→100%; відкат - у зворотному порядку (100→25→5→0).
Blue-Green: атомарний світч трафіку між Blue і Green, відкат - миттєве повернення.
Feature Flags: kill-switch для поведінкових змін (TTL, guardrails, SoD).
Config as Data: GitOps-промоут/ре-промоут попередньої версії; runtime-снапшоти.

• двофазні (expand→contract),
• reversible (down-скрипти),
• write-shadow (нові поля пишуться дубльовано),
• read-compat (старий код розуміє нову схему).

5) Політики відкату (policy-engine)

• `auto_rollback if auth_success_rate. drop(geo="TR") > 10% for 10m AND coverage>=5%`
• `auto_rollback if bet_settle_p99 > SLO1. 25 for 15m`
• `auto_pause_flag if api_error_rate > 1. 5% for 5m`
• `deny_promote if slo_red in {"auth_success","withdraw_tat_p95"}`
• `require_dual_control if change. affects in {"PSP_ROUTING","PII_EXPORT"}`

Всі правила версіонуються, тестуються і проходять рев'ю.

6) Потік авто-відкату (end-to-end)

1. Детектор регресії спрацьовує (метрика/алерт/валідатор).
2. Перевірка винятків (святкові піки, тестові вікна).

7) Інтеграції

Інцидент-бот: '/release rollback <id>', авто-таймлайни, посилання на дашборди і дифи.
Metrics API: готові SLO-в'ю і guardrail-статуси; exemplars для RCA.
Feature Flags: '/flag off <id>', автопауза по guardrail.
GitOps/Config: `/config rollback <snapshot>`; drift-детектор підтверджує результат.
Status-сторінка: опціональні публічні апдейти (через CL/політику).

8) Спостережуваність і телеметрія відкату

Release Dashboard: auth-success, error-rate, p95/p99, settle throughput, PSP по GEO/BIN.
Guardrail Board: активні/спрацювали правила, вікна, гістерезис.
Історія покриттів: % канареї/прапорів/регіонів у часі.
Аудит: хто/що/коли/навіщо; дифи артефактів; версія політик; результат.

9) Безпека, SoD і комплаєнс

4-eyes/JIT для дій, що впливають на платежі/PII/RG.
Geo-fences: відкати, що зачіпають регуляторні вимоги, застосовуються локально.
WORM-журнали: незмінний слід для перевірок.
Публічні комм-пакети: узгоджуються з CL/Legal; деталі експериментів назовні не розкриваються.

10) Приклади артефактів

10. 1 Політика авто-відкату (YAML)

yaml apiVersion: policy.platform/v1 kind: AutoRollbackRule metadata:
id: "payments-auth-success-tr"
spec:
scope: { tenants: ["brandA","brandB"], regions: ["EU"], geo: ["TR"] }
signal:
metric: "auth_success_rate"
condition: "drop > 10% for 10m"
compareTo: "canary_control"
action:
strategy: "step_down"  # 100%->25%->5%->0%
cooldown: "15m"
exceptions:
calendar: ["2025-11-29:black_friday"]
manualOverride: false audit:
owner: "Payments SO"
riskClass: "high"

10. 2 Маніфест відкату конфігурації

yaml apiVersion: cfg.platform/v1 kind: ConfigRollback metadata:
id: "psp-routing-revert-2025-11-01"
spec:
from: "payments-routing-2025-11-01"
to:  "payments-routing-2025-10-29"
criteria:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"
notify:
incidentBot: true stakeholders: ["Payments","SRE","Support"]

10. 3 Kill-switch прапора

yaml apiVersion: flag.platform/v1 kind: KillSwitch metadata:
id: "deposit.flow.v3"
spec:
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_green:auth_success"]
autoPauseOnBreach: true ttl: "30d"

11) Робота з міграціями даних

• Expand: додати нові колонки/індекси, не ламаючи читання.
• Migrate: подвійний запис/реплей, звірка консистентності.
• Contract: видалення старого тільки після успішного релізу + вікна спостереження.
• Down-скрипти: обов'язкові; оцінка часу і блокувань.
• Shadow-читання: порівняння результатів старого/нового шляху (без побічних ефектів).
• Критерії скасування contract: будь-який guardrail «червоний».

12) Процеси і RACI

Release Manager: власник конвеєра і політик.
Service Owner: затверджує правила домену, приймає ризик.
SRE: реалізує детектори, механіки відкату, дашборди.
Security/Compliance: SoD, PII/RG-контроль, аудит.
On-call IC/CL: комунікації, статус-сторінка.
CAB: пост-фактум огляд авто-відкатів, коригування правил.

13) KPI/KRI функції

Auto-Rollback Rate: частка релізів, що відкотилися автоматично (норма: низька, але не нульова).
Time-to-Rollback: detekt→otkat (медіана/п95).
SLO-Breach Avoided: випадки, коли авто-відкат запобіг порушенню цілей.
False Positives: частка «помилкових» відкатів (мета - ↓).
CFR до/після впровадження авто-відкату.
Cost of Rollbacks: додатковий час, канарки, обчислювальні ресурси.
Audit Completeness: % подій з повним таймлайном і диффами.

14) Дорожня карта впровадження (6-10 тижнів)

Нед. 1–2: каталог критичних метрик і базових порогів; вибір стратегій (canary/blue-green/flags); інвентаризація оборотності міграцій.
Нед. 3–4: реалізація детекторів і policy-engine; інтеграція з інцидент-ботом; GitOps-rollback для конфігов; дашборди guardrails.
Нед. 5–6: пілот на домені Payments (auth-success, PSP-роутинг), тренування tabletop; журнал WORM і звіти.
Нед. 7–8: розширення на Games/KYC; автоматична пауза прапорів; DR-навчання з blue-green.
Нед. 9–10: калібрування порогів, зниження false positive, FinOps-оцінка вартості, формалізація RACI і навчання.

15) Антипатерни

«Відкотимо якось»: відсутність плану і оборотності міграцій.
Глобальна миттєва активація/деактивація без ступенів.
Відкат по сирих метриках без контексту (немає стратифікації GEO/PSP/BIN).
Ігнор SRM і peeking в експериментах.
Реліз-алерти без гістерезису → флапінг відкатів.
Ручні правки конфігів в проді без Git/Audit.
Видалення старої схеми до проходження вікна спостереження.

Підсумок

Автоматичний відкат релізів - це захисна сітка платформи: політики як код, коректно вибрані сигнали і пороги, оборотні архітектурні рішення (canary/blue-green/flags/reversible migrations), вбудовані комунікації і повний аудит. Такий контур різко знижує ризик релізів, захищає SLO і виручку і підвищує довіру регуляторів і партнерів.