Auto-healing і самовідновлення

(Розділ: Технології та Інфраструктура)

Коротке резюме

Auto-healing - це не «магія Kubernetes», а набір дисциплін: коректні проби і ліміти, контрольовані ретраї, ізоляція несправних інстансів, автоматика по SLO і рунабук-дії по кнопці/ботом. Мета - скоротити MTTR без «снігового коми» перевантажень і зберегти p95/p99, платежі і TTW навіть в піку.

1) Принципи самовідновлення

1. Fail-fast & isolate: швидко виявляйте та ізолюйте погані поди/інстанси.
2. Backoff + jitter: будь ретрай/скейл-аут - з експоненціальною затримкою і джиттером.
3. SLO-aware: автоматика включається/посилюється при fast-burn бюджету помилок.
4. Idempotency: повтор операцій безпечний (особливо платежі/черги).
5. Defense in depth: проби, квоти, ліміти, circuit-breaker, outlier-ejection, rate-limit, деградаційний режим.

2) Базис в Kubernetes

2. 1 Проби: liveness / readiness / startup

startupProbe захищає від передчасних рестартів важких сервісів.
readinessProbe визначає готовність до трафіку (прогріті кеші/з'єднання).
livenessProbe перезапускає «завислі» процеси.

yaml readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3

livenessProbe:
httpGet: { path: /health/live, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3

startupProbe:
httpGet: { path: /health/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 30

2. 2 Ліміти, PDB і пріоритети

requests/limits виключають «noisy neighbor».
PodDisruptionBudget (PDB) запобігає одночасному падінню всіх подів.

yaml apiVersion: policy/v1 kind: PodDisruptionBudget spec:
minAvailable: 2 selector: { matchLabels: { app: payments-api } }

PriorityClass для критичних шляхів (payments, gateway).

2. 3 Перезапуск і стратегія деплоя

`maxUnavailable: 0'для критичних сервісів; rollingUpdate з малим кроком.
PodAntiAffinity розподіляє поди по нодах/зонах.

3) Автоскейлінг і подієве масштабування

HPA (CPU/призначені для користувача метрики)

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
minReplicas: 3 maxReplicas: 30 metrics:
- type: Resource resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
- type: Pods pods:
metric:
name: http_requests_per_second target:
type: AverageValue averageValue: "50"

VPA

Використовуйте для фонових воркерів/пакетних завдань; в прод-API - обережно (перезапуски).

KEDA (черги/зовнішні події)

Тригери по Kafka lag, RabbitMQ, Redis, Prometheus-запитам - збільшуємо споживачів, коли накопичується робота.

4) Мережеві захисти: circuit-breaker і вибраковка «поганих»

Envoy/Istio outlier detection (идея)

yaml outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

Circuit breaker обмежує одночасні запити/підключення, щоб не впустити залежність.

Rate limiting

Лімітуйте вхідні виклики/PSP-маршрути/ігрових провайдерів, щоб хвиля ретраїв не посилювала аварію.

5) Ретраї, таймаути і backoff з джиттером

Правило: спочатку таймаут, потім ретрай, завжди з джиттером і обмеженням спроб.

python def backoff(attempt, base=0. 1, cap=2. 0):
import random, math sleep = min(cap, base (2 attempt))
jitter = random. uniform(0, sleep 0. 4)
return sleep + jitter

Для платежів - ідемпотентні ключі + дедуплікація.
Для черг - dead-letter і відкладені повторні спроби.

6) Самовідновлення в чергах/стрімінгу

DLQ + алерти на зростання; ізольований репроцесинг.
Контроль lag: авто-скейл консьюмерів (KEDA), backpressure до продюсерів.
Exactly-once/at-least-once - вибирається усвідомлено; операції - ідемпотентні.

7) Кеші і warm-up

Версійні ключі ('v2:') для безпечної інвалідації/відкату.
Теплі пули з'єднань до БД/PSP; прогрів перед перемиканнями (blue-green/canary).
Stale-while-revalidate для зниження «холодних» ударів по БД.

8) Auto-remediation по SLO (дії по сигналах)

• Stop canary / rollback при fast-burn.
• Scale-out воркерів при зростанні'queue _ lag _ seconds'.
• Включення degrade-mode (спрощений UX, відключення важких фіч).
• Перемикання PSP-маршруту при timeouts spike.
• Активація feature-flag kill-switch.

yaml alert: WithdrawalsQueueLag labels: { action: "scale_workers", target: "withdrawals-consumers", by: "+5" }

9) Деградаційний режим (graceful degradation)

Спростити UI (менше запитів), вимкнути «дорогі» віджети.
Більше кешування, менше фан-аутів/аггрегацій.
Для LLM/рекомендацій - знизити розмір контексту/модель, включити «fast path».

10) GitOps-підхід до автоспрямувань

Всі політики auto-remediation і параметри (таймаути, пороги) - в Git.
Будь-яка автоматична дія створює анотацію в Grafana і запис в журналі змін.
Canary-політики і SLO-гейти - теж код.

11) Хаос-інжиніринг: перевіряємо, що healing працює

Ін'єкції збоїв: затримки мережі, падіння подів, відмова PSP-емулятора, лаг черги.
Сценарії game-day: вимірюємо MTTR, якість авто-дій, наявність артефактів.
Результати → оновлення рунабуків, порогів, фічефлагів.

12) Спостережуваність для auto-healing

Exemplars: швидкий стрибок з метрики p95 в трасу.
Логи з'trace _ id'і полями'retry','attempt','degrade _ mode = true'.
Дашборди release compare (stable vs canary), карта SLO.
Аудит авто-дій: хто/що/коли, вихідні метрики, результат.

13) Безпека та відповідність

Ніяких секретів в логах/метриках авто-ремедіацій.
Для дій над платежами - подвійне підтвердження/роль.
Гео/PII - не відводьте трафік в «не той» регіон при фейловері.

14) Практичні шаблони

Istio DestinationRule — connection pool & outlier

yaml trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1000, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

Flagger - canary c автопромоушеном/відкатом

yaml analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

KEDA ScaledObject — Kafka lag

yaml triggers:
- type: kafka metadata:
topic: withdrawals bootstrapServers: broker:9092 consumerGroup: w-consumers lagThreshold: "5000"

15) Чек-лист впровадження

1. Налаштовані startup/readiness/liveness і health-ендпоінти.
2. Ліміти/запити ресурсів + PDB/anti-affinity.
3. HPA/KEDA для API і воркерів; метрики lag/throughput.
4. Circuit-breaker, outlier-ejection, rate-limit в гейті/меші.
5. Ретраї з backoff + jitter, ідемпотентність платіжних операцій.
6. Версійні кеші і degrade-mode.
7. SLO-гейти → авто-дії (rollback/scale/reroute/kill-switch).
8. GitOps-код політик + аудит дій, анотації релізів.
9. Хаос-тести і game-day на ключові сценарії.
10. Дашборди MTTR/Alert Quality та звіти по авто-ремедіаціям.

16) Анти-патерни

Liveness «прибиває» процес через тимчасову залежність → флапінг.
Ретраї без таймаутів/джиттера → шторм запитів.
HPA по CPU при IO-залежних сервісах → «в нікуди».
Загальний кеш без версій при відкатах → псування даних.
Автоматичні дії без аудиту/Runbook URL.
Немає DLQ/метрик lag → тихе накопичення боргу.
Змішування auto-healing і «приховування проблем»: автоматика лікує симптоми, корінь не усувається → повтор інцидентів.

Підсумки

Самовідновлення - це інженерна дисципліна: якісні проби та ліміти, грамотні ретраї та ізоляція, автоматичні дії за SLO-сигналами, плюс хаос-перевірки та аудит. Такий контур робить платформу стійкою до збоїв, скорочує MTTR і береже ключові метрики iGaming - p99, конверсію платежів і TTW - навіть в найгарячіші години.