Auto-Healing і self-recovery систем

1) Що таке auto-healing і навіщо він потрібен

Auto-healing - це автоматична стабілізація сервісу при збоях без участі людини, з пріоритетом відновлення симптомів (SLO) над пошуком першопричини (RCA).
Цілі: знизити MTTR, захистити помилковий бюджет, скоротити операційні витрати і людські помилки.

• Детект (метрики/логи/синтетика/події).
• Рішення (правила/політики/ML-евристики).
• Дія (рестарт/скейл/шеддинг/фічефлаг/роллбек/фейловер).
• Верифікація (SLO зелений в задане вікно).
• Скасування (revert) при погіршенні.

2) Карта механізмів auto-healing

На рівні додатку: idempotency, timeouts, retry + backoff + jitter, circuit breaker, bulkhead, кеш-деградація (graceful).
Kubernetes: liveness/readiness/startup probes, restartPolicy, PDB, HPA/VPA, Descheduler, Pod/Node auto-remediation.
Мережа/edge: rate limits, пер-тенантні квоти, connection draining, fail-open/close, WAF-правила.
Черги/стрімінг: consumer-autoscale, lag-based backpressure, DLQ/parking lot.
Сховища/БД: репліка-фейловер, авто-ремонт (rebuild), throttled autovacuum, connection pool rebalancing.
CI/CD: канарні викладки, progressive delivery, авто-rollback.
Оркестрація подій: контролери/оператори, workflow-рушії (Argo, Airflow) з retry-політиками.
Watchdog/Heartbeats: Dead Man's Switch для фонових джоб.

3) Принципи проектування безпечного self-recovery

1. SLO-driven: всі автоматичні дії запускаються за симптомами, прив'язаними до користувацького досвіду.
2. Canary-first: спочатку локально/точково, потім - глобально.
3. One-way door guardrails: відкат по таймеру/умові, «подвійний ключ» для ризикованих операцій.
4. Idempotency: кожна дія (рестарт, міграція, ротація) безпечна при повторі.
5. Observability-by-design: мітки дій, кореляція з трасами, журнал «хто/що/коли/чому».
6. Least privilege: у автоматики мінімальні права (RBAC, scoped secrets).
7. Cost-aware: ліміти на «дорогі» дії (масштабування, egress, снепшоти).

4) Детект: сигнали для запуску auto-healing

Метрики: 5xx%, p95/p99 latency, Kafka lag, DB lock/lag, node pressure.
Синтетика: падіння аптайма/регрес шляху (логін/депозит).
Логи: нові сигнатури помилок, частота винятків.
Події K8s: CrashLoopBackOff, NodeNotReady, FailedScheduling.
Heartbeat: тиша джоби> N хвилин.

promql
API error regression sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Kafka: lag> threshold max by (topic, group) (kafka_consumergroup_lag)> 10000

K8s: pod в CrashLoopBackOff increase(kube_pod_container_status_restarts_total[5m]) > 3

5) Дії авто-відновлення (playbook-каталог)

5. 1 Додаток/мережа

Circuit breaker ON при аномії бекенду → швидкий fail-fast + кеш/стаб-відповіді.
Retry + backoff + jitter з лімітами та дедублікацією.
Rate limit/shed-load: при перевантаженні - пріоритизація критичних шляхів.

5. 2 Kubernetes

Рестарт контейнера (liveness) і видалення пода на не-здоровій ноді.
HPA/VPA: авто-скейл по RPS/CPU/latency/lag; VPA - тільки рекомендації або off-hours apply.
Авто-ремедіація нод: cordon + drain при persistent-проблемах (taints).
Affinity/Topology spread для захисту від AZ-фейлів.

5. 3 Черги/стрімінг

Auto-scale consumers по lag; тимчасове зниження throughput producers.
DLQ для отруйних повідомлень; replay з архівів.

5. 4 БД/кеш

Failover на репліку з перевіркою стейту/конфігурації.
Connection pool reset при «витоках» з'єднань.
Hot-standby promote з автоматичним reconfigure клієнтів.

5. 5 CI/CD

Авто-rollback при зростанні 5xx/p95 на канарському трафіку.
Feature-flags: автоматичне OFF проблемної фічі замість глобального відкату.

6) Progressive delivery і авто-rollback

Приклад (Argo Rollouts канарська стратегія)

yaml strategy:
canary:
canaryService: api-canary stableService: api-stable steps:
- setWeight: 10
- pause: {duration: 5m}
- analysis:
templates:
- templateName: api-slo-check
- setWeight: 25
- pause: {duration: 10m}
- analysis:
templates:
- templateName: api-slo-check

Якщо аналіз-темплейт повертає «fail» (перевищені помилки/латентність) - rollout автоматично відкочується.

7) Фіча-прапори як інструмент self-recovery

Kill-switch для проблемних фіч (server-side).
Таргетинг: відключати фічу на сегменті/регіоні.
Авто-правило: якщо 5xx% з фічі> X за Y хвилин - OFF і тікет в backlog.
Верифікація: SLO-панель фіч з бюджетами.

8) Перевантаження: як не «лікувати» себе до смерті

Shed-load: відхиляти/знижувати QoS не-критичних запитів (тарифи, heavy-звіти).
Token-bucket/leaky-bucket і квоти на тенанта/ключ.
Adaptive concurrency (на рівні проксі/SDK) - знижувати паралелізм при зростанні латентності.
Bulkhead: ізоляція пулів потоків/з'єднань.

9) Консистентність та ідемпотентність

Ідемпотентні ключі (request_id) → захист від повторів.
Побоюються операції (платежі, списання) - двофазні процеси, підтвердження/компенсація (saga).
Outbox/Inbox и exactly-once через idempotency storage.

10) Безпека та комплаєнс

Мінімальні RBAC для автоматик (тільки потрібні ресурси).
Аудит всіх дій: хто/коли/який сигнал/який ефект.
Ручний override і «червона кнопка» для відключення авто-дій.
Legal Hold на артефакти інциденту і журнали автоматики.
Секрети - через секрет-менеджер, ротація ключів при самодействиях.

11) ФінОпс: ціна «самозцілення»

Ліміти на максимальний autoscale, щоб не розоритися при сплеску.
Cost per action метрики: вартість 1 рестарта, 1 доп-репліки, 1TB egress.
Агрегати: cost per SLO-minute saved, cost per mitigated incident.
Політики «нічного режиму»: агресивність автоматики нижче, якщо бізнес-трафік низький.

12) Спостережуваність автоматики

Мітки на графах: `remediation_action="rollback"`, `source="argo"`, `reason="slo_burn"`.
Окремий дашборд: частота автодій, успішність, median recovery time, rollback rate.
Кореляція «дія → SLO» для оцінки користі.

13) Конфіги і приклади

13. 1 K8s: probes і рестарт-політики

yaml livenessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 timeoutSeconds: 2 readinessProbe:
httpGet: { path: /readyz, port: 8080 }
periodSeconds: 5 failureThreshold: 3 startupProbe:
httpGet: { path: /startupz, port: 8080 }
failureThreshold: 30 periodSeconds: 5

13. 2 Alert → auto-action (псевдо)

yaml rule: api_5xx_rate_high action:
type: feature_flag target: "payments. new_flow"
set: false guardrails:
cooldown: 10m max_actions_per_hour: 2 rollback_if:
- condition: "5xx% not reduced within 5m"

13. 3 Kafka lag autoscale (HPA з кастомної метрики)

yaml metrics:
- type: Pods pods:
metric:
name: kafka_consumer_lag target:
type: AverageValue averageValue: "500"

14) Тестування auto-healing (chaos & game days)

Chaos-ін'єкції: мережеві паузи, вбивство подів/нод, деградація БД/кешу.
Game days: сценарні тренування з тайм-лімітом і метриками MTTR.
Shadow traffic: прокат трафіку на канарю без впливу на користувачів.
Dry-run режими автоматики (пишемо, але не робимо).

15) Критерії «готовності до авто-відновлення»

• SLO визначені, метрики стабільні, є синтетика.
• Проби/healthz ,/readyz ,/startupz коректно відображають стан.
• Ідемпотентність і захист від дублів (особливо в платежах).
• Фіча-прапори і канарські викладки доступні.
• Guardrails: cooldown, rate-limit дій, подвійний ключ для високоризикових операцій.
• Дашборд автоматики і аудит-журнали.
• План «ручного override» і runbooks на випадок заклинювання.

16) Впровадження за етапами (4 ітерації)

1. База: визначте SLO, додайте probes, увімкніть рестарти/основні алерти.
2. Локальні дії: фічефлаг-kill-switch, лаг-скейлінг consumers, auto-rollback канарок.
3. Інфра-рівень: node remediation, failover БД/кешу, навантажувальне шеддинг.
4. Оптимізація: guardrails, FinOps-ліміти, chaos-тести, ML-евристики для детекту.

17) Часті помилки і анти-патерни

Лікуємо причину до симптомів → довгий MTTR.
Глобальні дії без канареечного етапу.
Немає відкату або відсутні критерії скасування.
Помилкові health-чеки (200 при зламаній залежності).
«Роздування» автоскейлу без лімітів/вартісних порогів.
Сліпа ретрай-буря без backoff і дедуплікації.

18) Міні-FAQ

Чи потрібен ML для авто-хілінгу?
Ні, ні. Почніть з правил по SLO/метрикам і guardrails; ML стане в нагоді для аномалій і предиктів.

Чому не завжди перезапуск допомагає?
Якщо корінь в залежності (БД, кеші, мережа), рестарт лише посилить шторм. Потрібні breaker/шеддинг/фейловер.

Як довести користь?
Порівняйте MTTR і споживання помилкового бюджету до/після. Додайте метрики cost per mitigation.

Підсумок

Auto-healing - це система, а не набір «рестарт-милиць»: SLO-детект → безпечні точкові дії → верифікація → відкат при погіршенні. Комбінуючи probes, канарні викладки, фіча-прапори, скейлінг, шеддинг, фейловери і строгі guardrails, ви скорочуєте MTTR, зберігаєте помилковий бюджет і тримаєте вартість під контролем.