Автоматическое исправление ошибок

1) Цель и принципы

Цель: сократить MTTR и предотвратить эскалацию инцидентов, сохранив SLO, выручку и соответствие требованиям.

• SLO-first: авто-действия разрешены только при подтвержденной угрозе бюджету ошибок.
• Безопасность прежде всего: минимальный blast-radius, явные лимиты и таймбоксы.
• Explainable by design: каждое действие объяснимо и аудируемо.
• Rollback-готовность: любой шаг сопровождается критериями возврата.
• Human-in-the-loop там, где риск высок: P1-критичные изменения — через dual control или подтверждение IC/он-коллом (если не установлено иное политикой).

2) Термины

Auto-remediation: программная реакция на событие (алерт/аномалия) без участия человека.
Guardrails: политика ограничений (порог, длительность, количество попыток, зона воздействия).
Runbook-Action: атомарная операция с пред/пост-проверками и откатом.
Decision Engine: сервис, который сопоставляет событие с политиками и запускает действия.

3) Архитектура решения

1. Сигналы: SLO/burn-rate, KRI, синтетика, RUM, deep-health.
2. Корреляция контекста: релизы, фичфлаги, плановые работы, зависимые провайдеры.
3. Decision Engine: правила/политики (policy-as-code), оценка импакта и риска, выбор сценария.
4. Выполнение: оркестратор runbook-действий (идемпотентность, ретраи с джиттером).
5. Контроль: пред-валидаторы, пост-верификаторы, таймбокс, откат.
6. Аудит и наблюдаемость: трейс действия, метрики успеха, журнал (WORM/immutable).
7. Коммуникация: статус-страница (через Comms Lead), вар-рум, макросы для саппорта.

4) Политики и допуски (policy-as-code)

• `allow if burn_rate(payments.auth) > fast && impact>threshold && psp_alt.healthy && within_limits("psp_reroute")`

• `allow if p99(bet_settlement)>3x && queue_lag>limit && feature("replay_center").enabled`

• `allow if consumer_lag>target && cost_budget.ok && region_capacity.available`

• `allow if export_spike && no_ticket && data_class=PII -> action=block + notify(Compliance)`

Каждая политика содержит: условие, действие, лимит (scope/время/частота), критерии успеха, откат.

5) Каталог безопасных действий (атомарные runbook-actions)

Платежи: переключить трафик на альтернативный PSP/банк; изменить приоритеты роутинга health×fee×conversion; включить упрощенный 3DS; повысить лимиты ретраев с джиттером.
Ставки/игры: масштабировать воркеры сеттла; включить cache-warmup; временно отключить некритичные фичи (анимации, вторичные фиды); включить waiting-room/queue-page.
Инфраструктура: изъять деградирующие экземпляры (outlier-detector), эвакуировать трафик в соседний AZ/регион; увеличить пул/квоты; перезапустить воркеры c линт-проверками.
Данные/очереди: перераспределить партиции; поднять потребителей до cap; переключить read-трафик на здоровую реплику; включить адаптивный семплинг трасс.
Безопасность/комплаенс: временно заблокировать экспорт PII без тикета; усилить velocity-лимиты выводов; включить dual control на чувствительные операции.
Комм-слой: авто-черновик статуса + слоты апдейтов для Comms Lead; уведомление партнеров при деградации PSP.

6) Пред- и пост-валидация

• Проверить, что проблема реальна и свежа (N-из-M окон; нет сайленса/плановых работ).
• Убедиться, что действие разрешено политикой и есть ресурсный бюджет.
• Оценить стоимость (FinOps) и комплаенс-ограничения.

• Подтвердить снижение burn-rate/метрик; записать результат; запланировать возврат (auto-rollback) по условиям.

7) Rollback и “escape hatch”

Авто-возврат при стабилизации метрик и через max-TTL действия.
Кнопка отката для IC/он-колла в вар-руме.
Break-glass только для аварийного доступа; обязателен пост-аудит.

8) Интеграция с алертингом и инцидентами

Любое auto-действие прикрепляется к карточке инцидента: кто/что/когда/почему, результат, ссылки на графики.
Пейджер приглушается для дубликатов, но не для неудачных авто-фиксов (эскалация).
Статус-страница обновляется через Comms Lead по шаблону.

9) Дизайн безопасности и комплаенса

Наименьшие привилегии для оркестратора; отдельные роли на действие/домен.
SoD и dual control для high-risk: PSP-роутинг, лимиты бонусов, экспорт PII.
Аудит WORM/immutable всех автоматических решений, включая входные сигналы и версии политик.
PII-гигиена: без персональных идентификаторов в лейблах и логах действий.

10) Наблюдаемость auto-контуров

Метрики: success-rate действий, время реакции, % откатов, экономия MTTR, влияния на SLO.
Трейсы: сквозные trace для “сигнал → решение → действие → эффект”.
Логи: структурированные, с policy_id, версиями и пред/пост-проверками.
Дашборды: Exec (влияние на выручку/SLO), Ops (матрица действий×домены), FinOps (стоимость авто-мер).

11) Примеры сценариев (iGaming)

11.1 PSP-деградация (TR/EU)

Сигнал: auth-success у PSP-1 ↓ на 25% за 10 мин, охват >30% транзакций.
Действия: перераспределить 40% трафика на PSP-2/3; включить упрощенный 3DS; поднять ретраи запросов банка X с джиттером.
Границы: не более 60% общего трафика на один альтернативный PSP; TTL 45 мин.
Rollback: при нормализации success-rate ≥ целевого в течение 15 мин.

11.2 Рост p99 у сеттла ставок

Сигнал: p99 “bet→settle” > 3× нормы + consumer-lag > порога.
Действия: scale-out воркеров до cap; прогрев кэша коэффициентов; временно выключить “историю повторов”.
Rollback: после headroom>Х и p99 в норме 20 мин.

11.3 Реплика БД отстает

Сигнал: replication-lag > N секунд, рост lock-wait.
Действия: отвести read-трафик на здоровую реплику; включить throttling write-операций низкого приоритета.
Rollback: после нормализации lag и ошибок блокировок.

11.4 Спайк экспортов PII

Сигнал: rate экспортов > базовой линии ×K, отсутствуют тикеты.
Действия: блок экспорта, уведомление Compliance, включение dual control.
Rollback: после подтверждения запросов и закрытия аномалии.

12) KPI и KRI

MTTR↓ для инцидентов, где сработал авто-фикс.
TTD→Action: время от детекта до выполнения действия.
Success-rate действий и Rollback-rate (низкий — хорошо, если не из-за ложных срабатываний).
False-action rate (действия без эффекта или с негативным эффектом).
SLO impact saved (минуты/выручка, предотвращенные штрафы).
Pager fatigue↓ (меньше ручных пейджеров при тех же/лучших SLO).

13) Дорожная карта внедрения (8–12 недель)

Нед. 1–2: выбрать 3–5 сценариев высокого ROI (PSP-фейловер, autoscale по lag, feature-degrade); описать политики/лимиты/откаты.
Нед. 3–4: реализовать оркестратор действий, секреты и роли, интеграцию с инцидент-платформой; добавить наблюдаемость и аудит.
Нед. 5–6: пилот в “теневом” режиме (simulate-only) → A/B-оценка эффекта; затем включить в прод с малым охватом.
Нед. 7–8: расширить каталог сценариев (БД/кэш/очереди/фронт), связать со статус-страницей и Comms.
Нед. 9–10: добавить правила FinOps-лимитов (стоимость/SLI), внедрить dual control для high-risk.
Нед. 11–12: tabletop/chaos-учения, пересмотр KPI/KRI, публикация гайдлайнов и обучение он-колла.

14) Артефакты и шаблоны

Auto-Remediation Policy: условие, действие, лимиты, TTL, откат, владелец, риск-класс.
Runbook-Action Spec: предусловия, шаги, проверки, ошибки, мониторинг, логика отката.
Change-Control: кто может править политики, PR-ревью, тесты, дифф и версия.
Evidence Pack: логи/трейсы/метрики воздействия на SLO, отчет для пост-мортема/аудита.

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

“Лечим симптом” без проверки причины и SLO → флаппинг.
Действия без отката и TTL → застывшие деградации.
Универсальные скрипты без guardrails → каскадные сбои.
Отсутствие аудита и версионирования политик.
Игнор стоимости (автоскейл без лимита) и комплаенса (PII-экспорты).
Полная автономия без Human-in-the-loop в P1-рисках.

Итог

Автоматическое исправление ошибок — это управляемый контур: SLO-сигналы → политики с guardrails → безопасные runbook-действия с откатом → наблюдаемость и аудит → обучение на инцидентах. Такой подход измеримо снижает MTTR, сохраняет выручку в пиках и снимает рутину с он-колла, оставаясь совместимым с требованиями безопасности и регуляторов.