Auto-healing va oʻz-oʻzini tiklash

(Bo’lim: Texnologiyalar va infratuzilma)

Qisqacha xulosa

Auto-healing - bu «Kubernetes sehri» emas, balki fanlar to’plami: to’g’ri sinov va limitlar, nazorat qilinadigan retralar, nosoz instantsiyalarni izolyatsiya qilish, SLO avtomatikasi va tugma/botdagi runabuk harakatlari. Maqsad - MTTRni ortiqcha yuklamasdan qisqartirish va p95/p99, to’lovlar va TTWni hatto cho’qqida saqlash.

1) O’zini o’zi tiklash prinsiplari

1. Fail-fast & isolate: yomon pod/instantsiyalarni tezda aniqlang va izolyatsiya qiling.
2. Backoff + jitter: har qanday retray/skeyl-out - eksponensial kechikish va jitter bilan.
3. SLO-aware: avtomatika fast-burn byudjetidagi xatolar bilan kuchaytiriladi.
4. Idempotency: operatsiyalarni takrorlash xavfsiz (ayniqsa toʻlovlar/navbatlar).
5. Defense in depth: namunalar, kvotalar, limitlar, circuit-breaker, outlier-ejection, rate-limit, degradatsiya rejimi.

2) Kubernetesdagi bazis

2. 1 Namunalar: liveness/readiness/startup

startupProbe ogʻir xizmatlarni muddatidan oldin qayta tiklashdan himoya qiladi.
readinessProbe trafikka tayyorligini aniqlaydi (isitilgan keshlar/ulanishlar).
livenessProbe «osilgan» jarayonlarni qayta boshlaydi.

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 Limitlar, PDB va ustuvorliklar

requests/limits «noisy neighbor» ni chiqarib tashlaydi.
PodDisruptionBudget (PDB) barcha podalarning bir vaqtning oʻzida yiqilishining oldini oladi.

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

Kritik yoʻllar uchun PriorityClass (payments, gateway).

2. 3 Deployni qayta ishga tushirish va strategiya

tanqidiy servislar uchun’maxUnavailable: 0’; rollingUpdate.
PodAntiAffinity tovoqlarni nod/zonalarga taqsimlaydi.

3) Avtoskeyling va voqealarni masshtablash

HPA (CPU/foydalanuvchi metrikasi)

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

Orqa fon vorkerlari/paket vazifalari uchun foydalaning; prod-API - ehtiyotkorlik bilan (qayta ishga tushirish).

KEDA (navbatlar/tashqi hodisalar)

Kafka lag, RabbitMQ, Redis, Prometheus-so’rovlar bo’yicha triggerlar - ish to’planganda iste’molchilarni ko’paytiramiz.

4) Tarmoq himoyasi: circuit-breaker va «yomon»

Envoy/Istio outlier detection (идея)

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

Circuit breaker bogʻliqlikni pasaytirmaslik uchun bir vaqtning oʻzida soʻrovlarni/ulanishlarni cheklaydi.

Rate limiting

Retraj to’lqini avariyani kuchaytirmasligi uchun kirish qo’ng’iroqlarini/PSP yo’nalishlarini/o’yin provayderlarini cheklang.

5) Retray, taymaut va backoff bilan jitter

Qoida: avval taymout, keyin retraj, har doim jitter va urinishlar cheklangan.

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

To’lovlar uchun - idempotent kalitlari + deduplikatsiya.
Navbatlar uchun - dead-letter va kechiktirilgan takroriy urinishlar.

6) Navbatlarda/strimingda o’zini o’zi tiklash

DLQ + o’sish uchun alertlar; izolyatsiya qilingan reprotsessing.
lag nazorati: avto-skeyl konsumerlari (KEDA), prodyuserlarga backpressure.
Exactly-once/at-least-once - ongli ravishda tanlanadi; operatsiyalar - idempotentlar.

7) Keshlar va warm-up

Xavfsiz nogironlik/qaytarish uchun versiya kalitlari (’v2:’).
DB/PSP ga ulanishlarning issiq pullari; almashtirishdan oldin isitish (blue-green/canary).
DBga «sovuq» zarbalarni kamaytirish uchun Stale-while-revalidate.

8) SLO bo’yicha auto-remediation (signallar bo’yicha harakatlar)

• Stop canary / rollback при fast-burn.
• ’queue _ lag _ seconds’ oʻsishida vorkerlarning scale-out.
• Degrade-mode (soddalashtirilgan UX, ogʻir fichlarni oʻchirish) ni yoqish.
• Timeouts spike’da PSP yoʻnalishini oʻzgartirish.
• Feature-flag kill-switch.

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

9) Degradatsiya rejimi (graceful degradation)

UI (kamroq soʻrov) ni soddalashtirish, «qimmat» vidjetlarni oʻchirish.
Koʻproq keshlash, kamroq fan-autlar/agregatsiyalar.
LLM/tavsiyalar uchun - kontekst/model hajmini kamaytirish, «fast path» ni kiritish.

10) GitOps - avto tuzatishlarga yondashuv

Barcha auto-remediation siyosati va parametrlari (taymautlar, chegaralar) - Git.
Har qanday avtomatik harakat Grafana izohini va oʻzgarishlar daftariga yozuvni yaratadi.
Canary-siyosatchilar va SLO-geytlar ham kod hisoblanadi.

11) Xaos-injiniring: healing ishlashini tekshiramiz

Nosozliklar inyeksiyalari: tarmoqning kechikishi, podaning yiqilishi, PSP-emulyatorning nosozligi, navbat orqasi.
Game-day stsenariylari: MTTR, avto-harakatlar sifati, artefaktlar mavjudligini o’lchaymiz.
Natijalar → Runabuklar, ostonalar, fizeflaglarni yangilash.

12) Auto-healing uchun kuzatish

Exemplars: p95 metrikasidan trassaga tez sakrash.
’trace _ id’ va’retry’,’attempt’,’degrade _ mode = true’.
Dashbordlar release compare (stable vs canary), SLO xaritasi.
Avto-harakatlar auditi: kim/nima/qachon, boshlang’ich metriklar, natija.

13) Xavfsizlik va muvofiqlik

Avto-remediatsiya daftarlarida/metrikalarida hech qanday sir yo’q.
To’lovlar bo’yicha harakatlar uchun - ikki tomonlama tasdiqlash/rol.
Geo/PII - feylover paytida trafikni «notoʻgʻri» mintaqaga olib bormang.

14) Amaliy shablonlar

Istio DestinationRule — connection pool & outlier

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

Flagger - canary avtosanoat/qaytish

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) Joriy etish chek-varaqasi

1. Startup/readiness/liveness va health-endpointlar sozlandi.
2. Resurs limitlari/so’rovlari + PDB/anti-affinity.
3. API va voryerlar uchun HPA/KEDA; lag/throughput metrikasi.
4. Circuit-breaker, outlier-ejection, rate-limit.
5. Backoff + jitter bilan retray, to’lov operatsiyalarining idempotentligi.
6. Version keshlari va degrade-mode.
7. SLO-geytlar → avto-harakat (rollback/scale/reroute/kill-switch).
8. GitOps kodi + harakatlar auditi, relizlar izohlari.
9. Asosiy stsenariylarda xaos-testlar va game-day.
10. MTTR/Alert Quality dashbordlari va avto-remediatsiyalar bo’yicha hisobotlar.

16) Anti-patternlar

Liveness vaqtinchalik bog’liqlik tufayli jarayonni «pichoqlaydi» → flapping.
Taymaut/jittersiz retrailar → boʻron soʻrovlari.
IO bog’liq servislarda CPU bo’yicha HPA → «hech qaerga».
Maʼlumotlar buzilganda versiyasi boʻlmagan umumiy kesh.
Auditsiz avtomatik harakatlar/Runbook URL.
DLQ/metrik lag → qarzning jimgina to’planishi yo’q.
Auto-healing aralashmasi va «muammolarni yashirish»: avtomatika alomatlarni davolaydi, ildiz yo’q qilinmaydi → hodisalarning takrorlanishi.

Yakunlar

O’zini o’zi tiklash - bu muhandislik intizomi: sifatli sinov va limitlar, malakali retrajlar va izolyatsiya, SLO signallari bo’yicha avtomatik harakatlar, shuningdek, tartibsizlik tekshiruvi va audit. Bunday kontur platformani nosozliklarga chidamli qiladi, MTTRni qisqartiradi va eng issiq soatlarda ham iGaming - p99, to’lovlar konversiyasi va TTW - ning asosiy metrikalarini saqlaydi.