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) SLO бойынша Auto-remediation (сигналдар бойынша әрекеттер)

• Stop canary / rollback при fast-burn.
• 'queue _ lag _ seconds' өсуі кезінде воркерлердің Scale-out.
• Degrade-mode қосу (UX жеңілдетілген, ауыр бөлшектерді ажырату).
• timeouts spike кезінде PSP бағытын ауыстырып қосу.
• 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.
Кез келген автоматты әрекет Графана аңдатпасын және өзгерістер журналына жазба жасайды.
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 автоөнеркәсібі/кері қайтуы бар

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 процесті уақытша тәуелділіктен «соғады» → флаппинг.
Таймаусыз/джиттерсіз ретрайлер → сұраулар дауылы.
IO-тәуелді сервистер кезінде CPU бойынша HPA → «ешқайда».
Деректер бүлінген кезде нұсқасыз ортақ кэш.
Аудитсіз автоматты әрекеттер/Runbook URL.
Жоқ DLQ/метрикалық lag → борыштың тыныш жинақталуы.
Auto-healing араластыру және «проблемаларды жасыру»: автоматика симптомдарды емдейді, түбір жойылмайды → оқиғаларды қайталау.

Өзін-өзі қалпына келтіру - бұл инженерлік тәртіп: сапалы сынамалар мен лимиттер, сауатты ретра және оқшаулау, SLO-сигналдар бойынша автоматты әрекеттер, плюс хаос-тексерулер және аудит. Мұндай контур платформаны іркілістерге төзімді етеді, MTTR-ді қысқартады және iGaming-тің негізгі өлшемдерін - p99, төлем конверсиясын және TTW-ді - ең ыстық сағаттарда да сақтайды.