Автоматический откат релизов

1) Зачем нужен авто-откат

• снижает CFR и MTTR;
• защищает SLO (auth-success, p99 “ставка→сеттл”, 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: детект→откат (медиана/п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 и выручку и повышает доверие регуляторов и партнеров.