Auto-Healing va self-recovery tizimlari

1) auto-healing nima va nima uchun kerak

Auto-healing - bu asosiy sababni (RCA) topishda simptomlarni tiklash (SLO) ustuvorligi bilan insonning ishtirokisiz uzilishlarda xizmatni avtomatik ravishda barqarorlashtirishdir.
Maqsad: MTTRni kamaytirish, noto’g "ri byudjetni himoya qilish, operatsion xarajatlar va insoniy xatolarni kamaytirish.

• Detekt (metrika/logi/sintetika/hodisalar).
• Yechim (qoidalar/siyosat/ML-evristika).
• Harakat (restart/skeyl/shedding/ficheflag/rollbek/feylover).
• Tasdiqlash (belgilangan oynada yashil SLO).
• Yomonlashganda bekor qilish.

2) Auto-healing mexanizmlari xaritasi

Ilova darajasida: idempotency, timeouts, retry + backoff + jitter, circuit breaker, bulkhead, kesh degradatsiyasi (graceful).
Kubernetes: liveness/readiness/startup probes, restartPolicy, PDB, HPA/VPA, Descheduler, Pod/Node auto-remediation.
Tarmoq/edge: rate limits, per-tenant kvotalar, connection draining, fail-open/close, WAF qoidalari.
Navbatlar/striming: consumer-autoscale, lag-based backpressure, DLQ/parking lot.
Omborlar/DQ: replika-feylover, avto-ta’mirlash (rebuild), throttled autovacuum, connection pool rebalancing.
CI/CD: kanareykalar, progressive delivery, avto-rollback.
Tadbirlarni orkestrlash: retry-siyosatchilar bilan boshqaruvchilar/operatorlar, workflow-dvigatellar (Argo, Airflow).
Watchdog/Heartbeats: Dead Man’s Switch fon joblari uchun.

3) Xavfsiz self-recovery loyihalashtirish prinsiplari

1. SLO-driven: barcha avtomatik harakatlar foydalanuvchi tajribasiga bog’langan alomatlar bilan boshlanadi.
2. Canary-first: avval lokal/nuqtaviy, keyin - global.
3. One-way door guardrails: taymer/shartlar bo’yicha orqaga qaytish, xavfli operatsiyalar uchun «ikki tomonlama kalit».
4. Idempotency: har bir harakat (qayta boshlash, migratsiya, rotatsiya) takrorlanganda xavfsiz.
5. Observability-by-design: harakat belgilari, treklar bilan bogʻlanish, «kim/nima/qachon/nima» jurnali.
6. Least privilege: avtomatika minimal huquqlarga ega (RBAC, scoped secrets).
7. Cost-aware: «qimmat» harakatlar uchun limitlar (masshtablash, egress, snepshotlar).

4) Detekt: auto-healing ishga tushirish uchun signallar

Метрики: 5xx%, p95/p99 latency, Kafka lag, DB lock/lag, node pressure.
Sintetika: aptaymning pasayishi/yo’lning regressi (login/depozit).
Loglar: xatolarning yangi belgilari, istisnolar chastotasi.
События K8s: CrashLoopBackOff, NodeNotReady, FailedScheduling.
Heartbeat: jobning sukunati> N daqiqa.

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) Avto-tiklash harakatlari (playbook-katalog)

5. 1 Ilova/tarmoq

Circuit breaker ON + tezkor fail-fast + kesh/stab-javoblar.
Retry + backoff + jitter.
Rate limit/shed-load: ortiqcha yuklashda - kritik yo’llarning ustuvorligi.

5. 2 Kubernetes

Konteynerni qayta qurish (liveness) va sog’lom bo’lmagan burg’ulashda taglikni olib tashlash.
HPA/VPA: RPS/CPU/latency/lag bo’yicha avto-skeyl; VPA - faqat tavsiyalar yoki off-hours apply.
Avto-remediatsiya nod: persistent-muammolarda cordon + drain (taints).
AZ-fayllardan himoya qilish uchun Affinity/Topology spread.

5. 3 Navbatlar/striming

Auto-scale consumers по lag; throughput producers vaqtinchalik pasayishi.
zaharli xabarlar uchun DLQ; arxivdan replay.

5. 4 DB/kesh

Faylover steyt/konfiguratsiyani tekshirish uchun.
Connection pool reset ulanishlar «oqib chiqqanda».
Mijozlarning avtomatik reconfigure bilan Hot-standby promote.

5. 5 CI/CD

Avto-rollback 5xx/p95 o’sishda kanarey trafigida.
Feature-flags: Global orqaga qaytish o’rniga avtomatik OFF muammosi.

6) Progressiv delivery va avto-rollback

Misol (Argo Rollouts kanareyka strategiyasi)

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

Agar tahlil-templeyt «fail» ni qaytarsa (xato/latentlik), rollout avtomatik ravishda orqaga qaytadi.

7) Ficha-bayroqlar self-recovery vositasi sifatida

Muammolar uchun kill-switch (server-side).
Targeting: segment/mintaqada fichani oʻchirish.
Avto qoida: Agar fichdan 5xx%> X Y daqiqada - OFF va backlog chiptasi.
Verifikatsiya: SLO-panel fich bilan byudjet.

8) Ortiqcha yuklash: o’zini o’limgacha «davolamaslik»

Shed-load: QoS tanqidiy bo’lmagan so’rovlarni (tariflar, heavy-hisobotlar) rad etish/pasaytirish.
Token-bucket/leaky-bucket va tenanta/kalit uchun kvotalar.
Adaptive concurrency (proksi/SDK darajasida) - yashirin o’sishda parallellikni kamaytirish.
Bulkhead: oqim/ulanish hovuzlarini izolyatsiya qilish.

9) Konsistentlik va idempotentlik

Idempotent kalitlar (request_id) → takrorlashlardan himoya qilish.
Qo’rqinchli operatsiyalar (to’lovlar, hisobdan chiqarish) - ikki fazali jarayonlar, tasdiqlash/kompensatsiya (saga).
Outbox/Inbox и exactly-once через idempotency storage.

10) Xavfsizlik va komplayens

Avtomatika uchun minimal RBAC (faqat zarur resurslar).
Barcha harakatlar auditi: kim/qachon/qanday signal/qanday ta’sir.
Avtomatik harakatlarni o’chirish uchun qo’lda override va «qizil tugma».
Hodisa artefaktlari va avtomatika jurnallari uchun Legal Hold.
Sirlar - sirli menejer orqali, o’z-o’zidan harakat qilganda kalitlarni almashtirish.

11) FinOps: «o’zini o’zi davolash» narxi

Portlashdan qochish uchun maksimal autoscale chegarasi.
Cost per action metrika: 1 restart, 1 dop-replika, 1TB egress qiymati.
Agregatlar: cost per SLO-minute saved, cost per mitigated incident.
«Tungi rejim» siyosati: agar biznes trafigi past bo’lsa, avtomatikaning tajovuzkorligi pastroq.

12) Avtomatika kuzatilishi

’remediation _ action =’ rollback’’,’source =’argo’’,’reason =’slo _ burn’ustunlaridagi belgilar.
Alohida dashbord: avtomashinalar chastotasi, muvaffaqiyat, median recovery time, rollback rate.
Foydani baholash uchun «→ SLO» korrelyatsiyasi.

13) Konfigi va misollar

13. 1 K8s: probes va restart siyosati

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 (psevdo)

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 (kastom metrikasi bo’yicha HPA)

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

14) Test auto-healing (chaos & game days)

Chaos-inyeksiyalar: tarmoq pauzalari, podalar/nod o’ldirish, DB/kesh degradatsiyasi.
Game days: taym-limit va MTTR metriklari bilan ssenariy mashqlari.
Shadow traffic: foydalanuvchilarga ta’sir qilmasdan kanareyaga trafik ijarasi.
Dry-run avtomatika rejimlari (biz yozamiz, lekin qilmaymiz).

15) «Avto-tiklashga tayyorlik» mezonlari

• SLO aniqlangan, metriklar barqaror, sintetika mavjud.
• /healthz ,/readyz ,/startupz namunalari holatni to’g’ri aks ettiradi.
• Idempotentlik va dubllardan himoya qilish (ayniqsa to’lovlarda).
• Ficha-bayroqlar va kanareya qoplamalari mavjud.
• Guardrails: cooldown, rate-limit harakatlar, yuqori xavfli operatsiyalar uchun ikki tomonlama kalit.
• Avtomatika dashbordi va audit-jurnallar.
• «Qo’lda override» va tiqilib qolganda runbooks rejasi.

16) Bosqichlar bo’yicha joriy etish (4 ta iteratsiya)

1. Maʼlumot bazasi: SLOni aniqlang, probes qoʻshing, restartlar/asosiy alertlarni yoqing.
2. Lokal harakatlar: ficheflag-kill-switch, lag-skeyling consumers, auto-rollback kanareykalar.
3. Infra-daraja: node remediation, failover DB/kesh, yuk sheddingi.
4. Optimallashtirish: guardrails, FinOps-limitlar, chaos-testlar, detektor uchun ML-evristiklar.

17) Tez-tez xatolar va anti-patternlar

Sababni uzoq MTTR belgilarigacha davolaymiz.
Kanareykasiz global harakatlar.
Qaytarish yoki bekor qilish mezonlari mavjud emas.
Soxta health-cheklar (200 ta bog’liqlik buzilganda).
Avtoskeylni limitsiz/qiymat chegaralarisiz «puflash».
Backoff va deduplikatsiyasiz ko’r retray bo’roni.

18) Mini-FAQ

Avtoxiling uchun ML kerakmi?
Yo’q. SLO/metrik va guardrails qoidalaridan boshlang; ML anomaliyalar va taxminlar uchun foydalidir.

Nima uchun qayta ishga tushirish har doim ham yordam bermaydi?
Agar ildiz bog’liq bo’lsa (BD, keshe, tarmoq), restart bo’ronni yanada kuchaytiradi. Breaker/shedding/feylover kerak.

Foydasini qanday isbotlash mumkin?
MTTR va noto’g’ri byudjet iste’molini solishtiring. cost per mitigation metriklarini qoʻshing.

Jami

Auto-healing - bu restart qo’ltiqlar to’plami emas, balki tizim: SLO-detekt → xavfsiz nuqtaviy harakatlar → tekshirish → yomonlashganda orqaga qaytish. Probes, kanar, fich bayroqlari, skeyling, shedding, feyloverlar va qattiq gardrails bilan MTTRni qisqartirasiz, noto’g’ri byudjetni saqlaysiz va xarajatlarni nazorat qilasiz.