Автоматичне виправлення помилок

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/регіон; збільшити пул/квоти; перезапустити воркери з лінт-перевірками.
Дані/черги: перерозподілити партії; підняти споживачів до 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> X і 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, зберігає виручку в піках і знімає рутину з он-колла, залишаючись сумісним з вимогами безпеки і регуляторів.