Auto-Healing və self-recovery sistemləri

1) auto-healing nədir və niyə lazımdır

Auto-healing, ilkin səbəbin (RCA) tapılması üzərində simptomların bərpası (SLO) prioriteti ilə insan iştirakı olmadan uğursuzluqlar zamanı xidmətin avtomatik sabitləşdirilməsidir.
Məqsədlər: MTTR-i azaltmaq, səhv büdcəni qorumaq, əməliyyat xərclərini və insan səhvlərini azaltmaq.

• Detekt (metriklər/loglər/sintetika/hadisələr).
• Həll (qaydalar/siyasət/ML-evristics).
• Fəaliyyət (restart/skail/shedding/ficheflag/rollback/feylover).
• Yoxlama (müəyyən pəncərədə SLO yaşıl).
• Pisləşdikdə ləğv (revert).

2) Auto-healing mexanizmlərinin xəritəsi

Tətbiq səviyyəsində: idempotency, timeouts, retry + backoff + jitter, circuit breaker, bulkhead, cache deqradasiya (graceful).
Kubernetes: liveness/readiness/startup probes, restartPolicy, PDB, HPA/VPA, Descheduler, Pod/Node auto-remediation.
Şəbəkə/edge: rate limits, per-tenant kvotalar, connection draining, fail-open/close, WAF qaydaları.
Növbələr/axın: consumer-autoscale, lag-based backpressure, DLQ/parking lot.
Depolama/DB: replika-feylover, avtomatik təmir (rebuild), throttled autovacuum, connection pool rebalancing.
CI/CD: Kanarya, progressive delivery, auto-rollback.
Hadisələrin orkestrasiyası: retry siyasətçiləri ilə nəzarətçilər/operatorlar, workflow mühərrikləri (Argo, Airflow).
Watchdog/Heartbeats: Dead Man 's Switch fon cob üçün.

3) Təhlükəsiz self-recovery dizayn prinsipləri

1. SLO-driven: Bütün avtomatik hərəkətlər istifadəçi təcrübəsinə bağlı simptomlara görə başlayır.
2. Canary-first: əvvəlcə yerli/nöqtəli, sonra - qlobal.
3. One-way door guardrails: zamanlayıcı/şərt, riskli əməliyyatlar üçün «ikiqat açar».
4. Idempotency: hər bir hərəkət (restart, miqrasiya, rotasiya) təkrar edildikdə təhlükəsizdir.
5. Observability-by-design: hərəkət etiketləri, yollarla korrelyasiya, «kim/nə/nə vaxt/niyə» jurnalı.
6. Least privilege: avtomatika minimum hüquqlara malikdir (RBAC, scoped secrets).
7. Cost-aware: «bahalı» hərəkətlərə məhdudiyyətlər (ölçmə, egress, snepshotlar).

4) Detekt: avtomatik-healing başlamaq üçün siqnallar

Метрики: 5xx%, p95/p99 latency, Kafka lag, DB lock/lag, node pressure.
Sintetika: aptaym/reqress yolu (giriş/depozit).
Log: yeni səhv işarələri, istisnaların tezliyi.
События K8s: CrashLoopBackOff, NodeNotReady, FailedScheduling.
Heartbeat: Joba sükutu> N dəqiqə.

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) Avtomatik bərpa hərəkətləri (playbook-kataloq)

5. 1 Əlavə/şəbəkə

Circuit breaker ON backend anomiyası ilə → sürətli fail-fast + cache/stab-cavablar.
Retry + backoff + jitter limitləri və dublikatı ilə.
Rate limit/shed-load: həddindən artıq yükləndikdə - kritik yolların prioritetləşdirilməsi.

5. 2 Kubernetes

Qabın yenidən qurulması (liveness) və sağlam olmayan bir nodda pot çıxarılması.
HPA/VPA: RPS/CPU/latency/lag üzrə avtomatik skail; VPA - yalnız tövsiyələr və ya off-hours apply.
Auto-remediation nod: persistent problemlərdə cordon + drain (taints).
AZ fayllarından qorunmaq üçün Affinity/Topology spread.

5. 3 Növbələr/axın

Auto-scale consumers по lag; müvəqqəti azalma throughput producers.
zəhərli mesajlar üçün DLQ; arxivlərdən replay.

5. 4 BD/Cache

Steyt/konfiqurasiya yoxlama ilə replika Failover.
Bağlantıların «sızması» zamanı Connection pool reset.
avtomatik reconfigure müştərilər ilə Hot-standby promote.

5. 5 CI/CD

Kanarya trafikində 5xx/p95 böyümə ilə auto-rollback.
Feature-flags: qlobal geri dönüş əvəzinə avtomatik OFF problem fich.

6) Progressive delivery və auto-rollback

Nümunə (Argo Rollouts kanarya strategiyası)

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

Analiz temperatur «fail» (xətalar/gecikmə həddindən artıq) qaytarırsa, rollout avtomatik olaraq geri dönür.

7) self-recovery aləti kimi Ficha bayraqları

Problem üçün Kill-switch (server-side).
Hədəfləmə: seqment/regionda fiçanı söndürün.
Auto-qayda: 5xx% fich> X Y dəqiqə - OFF və backlog bilet.
Verifikasiya: SLO paneli büdcələrlə fich.

8) Həddindən artıq yük: ölümcül özünüzü necə «müalicə etməmək»

Shed-load: kritik olmayan sorğuların (tariflər, ağır hesabatlar) QoS rədd/aşağı.
Token-bucket/leaky-bucket və tenanta/açar üçün kvotalar.
Adaptive concurrency (proxy/SDK səviyyəsində) - gecikmə artdıqda paralelliyi azaltmaq.
Bulkhead: axınlar/birləşmələr hovuz izolyasiyası.

9) Tutarlılıq və idempotentlik

İdempotent açarları (request_id) → təkrarlardan qorunma.
Qorxulu əməliyyatlar (ödənişlər, silinmələr) - iki fazalı proseslər, təsdiq/kompensasiya (saga).
Outbox/Inbox и exactly-once через idempotency storage.

10) Təhlükəsizlik və uyğunluq

Avtomatika üçün minimum RBAC (yalnız lazımi resurslar).
Bütün hərəkətlərin auditi: kim/nə vaxt/hansı siqnal/hansı effekt.
Avtomatik hərəkətləri söndürmək üçün əl override və «qırmızı düymə».
Hadisənin artefaktları və avtomatika jurnallarında Legal Hold.
Sirlər - gizli menecer vasitəsilə, öz-özünə hərəkət edərkən açarların rotasiyası.

11) FinOps: «özünü müalicə» qiyməti

Maksimum autoscale limitləri.
Cost per action metriklər: 1 restarting dəyəri, 1 dop-replikalar, 1TB egress.
Aqreqatlar: cost per SLO-minute saved, cost per mitigated incident.
«Gecə rejimi» siyasəti: iş trafiki aşağı olduqda avtomatlaşdırmanın aqressivliyi aşağıdır.

12) Avtomatlaşdırma müşahidə

Qraflardakı etiketlər:' remediation _ action =» rollback»',' source =» argo»', 'reason = «slo _ burn»'.
Ayrı-ayrı dashboard: tezlik, müvəffəqiyyət, median recovery time, rollback rate.
Faydalarını qiymətləndirmək üçün «hərəkət → SLO» əlaqəsi.

13) Konfiqilər və nümunələr

13. 1 K8s: probes və restart siyasəti

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 (xüsusi metrika üzrə HPA)

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

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

Chaos inyeksiyaları: şəbəkə fasilələri, sui-qəsd/nod, deqradasiya BD/cache.
Game days: vaxt limiti və MTTR metrləri ilə ssenari məşqləri.
Shadow traffic: istifadəçilərə təsir etmədən kanareyaya trafik icarəsi.
Dry-run avtomatlaşdırma rejimləri (yazırıq, amma etmirik).

15) «Avtomatik bərpaya hazırlıq» meyarları

• SLO müəyyən, metrik sabit, sintetik var.
• /healthz ,/readyz ,/startupz nümunələri vəziyyəti düzgün əks etdirir.
• İdempotentlik və dubl qorunması (xüsusilə ödənişlərdə).
• Ficha bayraqları və kanarya astarları mövcuddur.
• Guardrails: cooldown, rate-limit hərəkətləri, yüksək riskli əməliyyatlar üçün ikiqat açar.
• Dashboard avtomatika və audit jurnalları.
• «Əl override» planı və sıxılma halında runbooks.

16) Mərhələlər üzrə tətbiq (4 iterasiya)

1. Baza: SLO-nu təyin edin, probes əlavə edin, restartları/əsas riskləri daxil edin.
2. Lokal hərəkətlər: ficheflag-kill-switch, lag-skeyling consumers, auto-rollback kanaryalar.
3. Infra-level: node remediation, failover BD/cache, yük shedding.
4. Optimizasiya: guardrails, FinOps-limitləri, chaos testləri, detektor üçün ML-evristiklər.

17) Tez-tez səhvlər və anti-nümunələr

simptomlar → uzun MTTR üçün səbəb müalicə.
Kanarya mərhələsi olmadan qlobal fəaliyyət.
Geri çəkilmə və ya ləğv meyarları yoxdur.
Saxta sağlamlıq çekləri (200 pozulmuş asılılıq ilə).
limit/dəyər həddi olmadan avtoskeyl «şişirmək».
backoff və deduplication olmadan kor retraj fırtına.

18) Mini-FAQ

Auto Hilling üçün ML lazımdır?
Yox. SLO/metrik və guardrails qaydaları ilə başlayın; ML anomaliyalar və proqnozlar üçün faydalıdır.

Niyə yenidən başlamaq həmişə kömək etmir?
Kök asılıdırsa (BD, cache, şəbəkə), restart yalnız fırtınanı ağırlaşdıracaq. Breaker/shedding/feylover lazımdır.

Faydalarını necə sübut etmək olar?
MTTR və/sonra səhv büdcə istehlakı müqayisə. cost per mitigation metrik əlavə edin.

Yekun

Auto-healing bir sistem deyil, «yenidən qurulmuş balta» dəsti: SLO-detekt → təhlükəsiz nöqtə hərəkətləri → yoxlama → pisləşdikdə geri dönüş. Siz MTTR azaldın, səhv büdcəni saxlayın və xərcləri nəzarət altında saxlayın.