Auto-Healing და self-recovery სისტემები

1) რა არის auto-healing და რატომ არის ეს საჭირო

Auto-healing არის სერვისის ავტომატური სტაბილიზაცია ადამიანის მონაწილეობის გარეშე ჩავარდნების დროს, სიმპტომების აღდგენის პრიორიტეტი (SLO) ძირითადი მიზეზის ძებნაში (RCA).
მიზნები: MTTR- ის შემცირება, მცდარი ბიუჯეტის დაცვა, ოპერაციული ხარჯების შემცირება და ადამიანის შეცდომები.

• დეტაჟი (მეტრიკა/ლოგები/სინთეზები/მოვლენები).
• გამოსავალი (წესები/პოლიტიკა/ML ევრაზიები).
• მოქმედება (restart/skale/sheadding/ficheflag/rollback/Faylover).
• გადამოწმება (SLO მწვანე მოცემულ ფანჯარაში).
• გაუქმება (შეცვლა) გაუარესების დროს.

2) Auto-healing მექანიზმების რუკა

განაცხადის დონეზე: idempotence, timeouts, retry + backoff + jitter, circuit breaker, bulkhead, ქეშის დეგრადაცია (graceful).
Kubernetes: liveness/readiness/startup probes, restartPolicy, PDB, HPA/VPA, Descheduler, Pod/Node auto-remediation.
ქსელი/edge: rate limits, pint-tenant კვოტები, დაკავშირება draining, fail-open/close, WAF წესები.
რიგები/ნაკადი: consumer-autoscale, lag-based backpressure, DLQ/parking lot.
საცავი/BD: რეპლიკა-ფეილოვერი, მანქანა-რემონტი, throttled autovacuum, კავშირი აუზის აღდგენა.
CI/CD: კანარის გამოთვლები, პროგრესული დისტრიბუცია, მანქანა-როლბაკი.
ღონისძიების ორკესტრი: კონტროლერები/ოპერატორები, workflow ძრავები (Argo, Airflow) retry პოლიტიკოსებით.
Watchdog/Heartbeats: Dead Man's Switch ფონის ჯობებისთვის.

3) უსაფრთხო სელფის დიზაინის პრინციპები

1. SLO-driven: ყველა ავტომატური მოქმედება იწყება მომხმარებლის გამოცდილებასთან დაკავშირებული სიმპტომების მიხედვით.
2. Canary-first: ჯერ ადგილობრივი/წერტილოვანი, შემდეგ გლობალური.
3. One-way door guardrails: გამოტოვება დროულად/პირობით, „ორმაგი გასაღები“ სარისკო ოპერაციებისთვის.
4. Idempotence: თითოეული მოქმედება (restart, მიგრაცია, როტაცია) უსაფრთხოა გამეორების დროს.
5. Observability-by-design: მოქმედების ეტიკეტები, მარშრუტებთან კორელაცია, ჟურნალი „ვინ/რა/როდის/რატომ“.
6. Least privilege: ავტომატიზაციას აქვს მინიმალური უფლებები (RBAC, სკოპირებული საიდუმლოებები).
7. Cost aware: limites „ძვირადღირებული“ მოქმედებებისთვის (სკალირება, egress, ფიფქები).

4) დეტაჟი: სიგნალები ავტო-ჰალინგის დასაწყებად

Метрики: 5xx%, p95/p99 latency, Kafka lag, DB lock/lag, node pressure.
სინთეტიკა: აფთიაქის/ბილიკის რეგრესიის ვარდნა (ლოგინი/ანაბარი).
ლოგიკა: შეცდომების ახალი ხელმოწერები, გამონაკლისების სიხშირე.
События K8s: CrashLoopBackOff, NodeNotReady, FailedScheduling.
Heartbeat: დუმილი ჯობი> N წუთი.

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) მანქანის აღდგენის მოქმედებები (playbook კატალოგი)

5. 1 პროგრამა/ქსელი

უკანა ანომალია Circuit breaker ON - სწრაფი fail-fast + cesh/mash პასუხები.
Retry + backoff + jitter ერთად limites და debectication.
Rate limit/shed-load: გადატვირთვისას - კრიტიკული ბილიკების პრიორიტეტი.

5. 2 Kubernetes

კონტეინერის გადატვირთვა და არაჯანსაღი ძილის მოცილება.
HPA/VPA: მანქანის სკეიტი RPS/CPU/latency/lag; VPA - მხოლოდ რეკომენდაციები ან off-hours appy.
Nod Auto remediation: cordon + drain პერსონალურ პრობლემებში (taints).
Affinity/Topology spread AZ ყალბებისგან დასაცავად.

5. 3 რიგები/ნაკადი

Auto-scale consumers по lag; throughput producers- ის დროებითი დაქვეითება.
DLQ შხამიანი შეტყობინებებისთვის; ანგარიში არქივიდან.

5. 4 BD/ქეში

Failover რეპლიკზე, სტატის/კონფიგურაციის შემოწმებით.
კავშირი აუზის აღდგენა ნაერთების „გაჟონვის“ დროს.
Hot-standby promote მომხმარებლების ავტომატური ჩანაწერებით.

5. 5 CI/CD

Auto-rollback 5xx/p95 ზრდის კანარის ტრაფიკზე.
Feature-flags: ავტომატური OFF პრობლემური ფიჩი გლობალური გამოტოვების ნაცვლად.

6) პროფესიული მიწოდება და მანქანა-როლბაკი

მაგალითი (Argo Rollouts კანარის სტრატეგია)

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

თუ Templait ანალიზს უბრუნდება „fail“ (შეცდომები/ლატენტობა აღემატება) - rollout ავტომატურად ბრუნდება.

7) Ficha დროშები, როგორც self-recovery ინსტრუმენტი

Kill-switch პრობლემური ფიგურებისთვის (სერვერის მხარე).
მიზნობრივი: გამორთეთ ფიჩი სეგმენტში/რეგიონში.
ავტო წესი: თუ 5xx% ფიჩიდან> X Y წუთში - OFF და ticket backlog.
გადამოწმება: SLO ფონური პანელი ბიუჯეტებით.

8) გადატვირთვა: როგორ მოვიქცეთ სიკვდილამდე?

Shed-load: QoS არა კრიტიკული მოთხოვნების უარყოფა/შემცირება (ტარიფები, მძიმე ანგარიშები).
Token-bucket/leaky-bucket და კვოტები ტენანტისთვის/გასაღებისთვის.
Adaptive concurrency (მარიონეტული/SDK) - პარალელიზმის შემცირება ლატენტობის ზრდის დროს.
Bulkhead: ნაკადის/ნაერთების ტყვიების იზოლაცია.

9) Consistence და idempotence

Idempotent გასაღებები (request _ id) - გამეორებისგან დაცვა.
საშიში ოპერაციები (გადახდა, ჩამოწერა) - ორფაზიანი პროცესები, დადასტურება/ანაზღაურება (საგა).
Outbox/Inbox и exactly-once через idempotency storage.

10) უსაფრთხოება და შესაბამისობა

მინიმალური RBAC ავტომატიზაციისთვის (მხოლოდ საჭირო რესურსები).
ყველა მოქმედების აუდიტი: ვინ/როდის/რა სიგნალი/რა ეფექტი.
სახელმძღვანელო override და „წითელი ღილაკი“ მანქანის მოქმედების გამორთვისთვის.
იურიდიული ჰოლდი ინციდენტის არტეფაქტებზე და ავტომატიზაციის ჟურნალებზე.
საიდუმლოებები - საიდუმლო მენეჯერის მეშვეობით, კლავიშების როტაცია თვითდახმარების დროს.

11) Finops: „თვითკურნების“ ფასი

მაქსიმალური autoscale ლიმიტები ისე, რომ არ გაანადგუროს.
Cost per action მეტრიკა: 1 გადატვირთვის ღირებულება, 1 დოპ-რეპლიკა, 1TB egress.
დანაყოფები: cost per SLO-minute saved, cost per mitigated incident.
„ღამის რეჟიმის“ პოლიტიკოსები: ავტომატიზაციის აგრესიულობა დაბალია, თუ ბიზნეს ტრაფიკი დაბალია.

12) ავტომატიზაციის დაკვირვება

ეტიკეტები გრაფიკებზე:' remediation _ action =“ rollback“',' source =“ argo“', 'reason = „slo _ burn“'.
ცალკეული დაშბორდი: ავტომობილების სიხშირე, წარმატება, საშუალო რეკონსტრუქციის დრო, rollback დრო.
კორელაცია „SLO მოქმედება“ სარგებლის შესაფასებლად.

13) კონფისკაცია და მაგალითები

13. 1 K8s: probes და restart პოლიტიკა

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 (ფსევდო)

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 (HPA კასტომის მეტრში)

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

14) ტესტირება auto-healing (chaos & game days)

Chaos ინექციები: ქსელის პაუზები, ქვე-მკვლელობა/ნოე, BD/ქეში დეგრადაცია.
თამაშის დღეები: სცენარის მომზადება დროული ლიმიტით და MTTR მეტრიკებით.
Shadow traffic: ტრაფიკის დაქირავება კანარზე, მომხმარებლებზე გავლენის გარეშე.
Dry-run ავტომატიზაციის რეჟიმები (ჩვენ ვწერთ, მაგრამ არ ვაკეთებთ).

15) კრიტერიუმები „მზადყოფნა მანქანის აღდგენისთვის“

• SLO განისაზღვრება, მეტრიკა სტაბილურია, არის სინთეზური.
• ნიმუშები/healthz ,/readyz ,/startupz სწორად ასახავს მდგომარეობას.
• Idempotence და დაცვა დუბლირებისგან (განსაკუთრებით გადახდებში).
• Fich დროშები და კანარის გამოთვლები ხელმისაწვდომია.
• Guardrails: cooldown, მოქმედებების საბაზო-ლიმიტი, მაღალი რისკის ოპერაციების ორმაგი გასაღები.
• დაშბორდის ავტომატიზაცია და აუდიტის ჟურნალები.
• „სახელმძღვანელო override“ გეგმა და runbooks შერწყმის შემთხვევაში.

16) დანერგვა ეტაპზე (4 გამეორება)

1. ბაზა: შეამოწმეთ SLO, დაამატეთ probes, ჩართეთ restarts/ძირითადი ალერტები.
2. ადგილობრივი მოქმედებები: ficheflag-kill-switch, lag skayling consumers, auto-rollback canares.
3. ინფრა დონე: node remediation, failover BD/ქეში, დატვირთული შედევრი.
4. ოპტიმიზაცია: guardrails, FinOps limites, chaos ტესტები, ML Euristics დეტექტისთვის.

17) ხშირი შეცდომები და საწინააღმდეგო ნიმუშები

ჩვენ ვექცევით სიმპტომების მიზეზს - გრძელი MTTR.
გლობალური მოქმედებები კანარის ეტაპის გარეშე.
არ არის გამოტოვებული ან არ არსებობს გაუქმების კრიტერიუმები.
ცრუ ჯანმრთელობის შემოწმებები (200 გატეხილი დამოკიდებულებით).
ავტო სკეიტის „გაბრაზება“ ლიმიტების/ღირებულების ბარიერების გარეშე.
ბრმა retray ქარიშხალი backoff- ის და დედაპლაციის გარეშე.

18) მინი-FAQ

გჭირდებათ ML მანქანის ჰილინგისთვის?
არა. დაიწყეთ SLO/მეტრიკის და guardrails წესებით; ML სასარგებლო იქნება ანომალიებისა და წინამორბედებისთვის.

რატომ არ უწყობს ხელს გადატვირთვა ყოველთვის?
თუ დამოკიდებულია ფესვი (BD, ქეში, ქსელი), რესტარტი მხოლოდ გაამძაფრებს ქარიშხალს. ჩვენ გვჭირდება breaker/shadding/faylover.

როგორ დავამტკიცოთ სარგებელი?
შეადარეთ MTTR და არასწორი ბიუჯეტის მოხმარება/შემდეგ. დაამატეთ მეტრიკები cost per mitigation.

შედეგი

Auto-healing არის სისტემა, და არა „restart-restilles“ ნაკრები: SLO დეტალი, უსაფრთხო წერტილოვანი მოქმედებები, გადამოწმება და უკან დაბრუნება, როდესაც გაუარესდება. Probes- ის, კანარის გამოთვლების, წინსვლის დროშების, სკეილინგის, შედარების, ფეილოვერების და მკაცრი guardrails- ის კომბინაციით, თქვენ ამცირებთ MTTR- ს, შეინარჩუნებთ არასწორ ბიუჯეტს და აკონტროლებთ ღირებულებას.