Chaos Engineering: სისტემების სტაბილურობა

Chaos Engineering: სისტემების სტაბილურობა

1) რატომ არის ქაოსის ინჟინერია

• შეამოწმეთ ჰიპოთეზები სისტემის ქცევის შესახებ და აკონტროლეთ SLO;
• იპოვნეთ ფარული SPOF, არასწორი Taimauts/retrais, stuntad ეფექტები;
• გაწვრთნილი ბრძანებები: თამაშის დღეები, runbooks, კომუნიკაციები;
• ჩამოაყალიბეთ კულტურის „ნაგულისხმევი სტაბილურობა“ და არა „საუკეთესოს იმედი“.

მნიშვნელოვანია: Chaos Engineering - „ყველაფრის დაშლა“. ეს არის სამეცნიერო მეთოდი: steady-state - ჰიპოთეზა - ექსპერიმენტი, დასკვნები და გაუმჯობესება.

2) ძირითადი ექსპერიმენტის ციკლი

1. Steady-state (საბაზო ხაზი): რომელი SLI სტაბილურია? (მაგალითად, წარმატება 500 ms 99. 95%).
2. ჰიპოთეზა: ერთი AZ p95 დაკარგვით, გაიზრდება <10%, ხოლო ხელმისაწვდომობა 99. 9%.
3. ექსპერიმენტი: დაგეგმილი ფალტი შეზღუდული blast radius და stop კრიტერიუმებით.
4. დაკვირვება: მეტრიკა/ტრეისი/ლოგები, ბურნი-ბარელი SLO, ბიზნეს SLI (მაგალითად, წარმატებული ანაბრები).
5. გაუმჯობესებები: ჩვენ ვაწარმოებთ აღმოჩენებს, ვცვლით ტაიმუთებს/ლიმიტებს/მარშრუტიზაციას, განაახლეთ runbook.
6. ავტომატიზაცია/რეგრესია: ვიმეორებთ გრაფიკში, დაამატეთ CI/CD და game-days კალენდრები.

3) პერილა უსაფრთხოების პირველი

Blast radius: დავიწყოთ ვიწრო - ერთი pod/instans/მარშრუტი/namespace.
Guardrails: ალერტები SLO burn-rate (სწრაფი/ნელი), რეაგირების ლიმიტები, QPS შეზღუდვა, ინციდენტის ბიუჯეტი.
Stop კრიტერიუმები: „თუ error-rate> X% ან p99> Y ms N წუთი არის მყისიერი გაჩერება და rollback“.
ფანჯრები: სამუშაო საათები on-call, ინფორმირებული სტეიკჰოლდერები, გაყინული გამოშვებები.
კომუნიკაცია: IC/Tech lead/Comms, ნათელი არხი (ომის ოთახი), შეტყობინებების შაბლონი.

4) უარის თქმის კლასები და ჰიპოთეზის იდეები

ქსელი: შეფერხება/ჯიტერი/ზარალი, ნაწილობრივი პორტების ნაკადი, სერვისებს შორის „ფუფუნება“ კავშირი/PSP.
კომპაქტური/კვანძები: პროცესების მკვლელობა, CPU გადახურება, ფაილური აღწერილობების ამოწურვა, ნაერთების ვიწრო აუზები.
საცავი და BD: latency დისკების ზრდა, რეპლიკების შეჩერება, ერთი ხარის/ლიდერის გაჩერება, split-brain.
დამოკიდებულება: გარე API- ს დეგრადაცია, პროვაიდერების ლიმიტები, 5xx/429 აურზაური.
ცვლილების მენეჯმენტი: წარუმატებელი გამოშვება, ცუდი ფიგურის დროშა, პარტიული როლი.
პერიმეტრი: CDN დეგრადაცია, DNS/Anycast drift, WAF/bot თავდაცვის უკმარისობა.
რეგიონი/AZ: სრული ზარალი ან „ნაწილობრივი“ ინციდენტი (ოდნავ უარესი და არაპროგნოზირებადი).

5) ხელსაწყოები და ტექნიკა

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
ღრუბლები: AWS Fault Injection Simulator (FIS), Fault Domains ღრუბლებში.
ქსელი/მარიონეტული: Toxiproxy (TCP შხამი), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
პროცესები/კვანძები: 'stress-ng', cgroups/CPU-throttle, disk fill.
მარშრუტის ტრაფიკი: GSLB/DNS კვირები, კანარი/ცისფერი-მწვანე გადართვა ყალბი შემოწმებისთვის.

6) სცენარების მაგალითები (Kubernetes)

6. 1 Delay/abort მარშრუტზე (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

ჰიპოთეზა: კლიენტის ტაიმაუტები/რეტრაი და CB შეინარჩუნებენ p95 <300 ms და error-rate <0. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

ჰიპოთეზა: დაბალანსება და HPA ანაზღაურებენ ერთი ნიმუშის ლოსებს p99> 20% ზრდის გარეშე.

6. 3 ქსელის ქაოსი (შეფერხება მონაცემთა ბაზაში)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

ჰიპოთეზა: აუზები/ტაიმაუტები/ქეში შეამცირებს გავლენას; p95 გადახდა დარჩება SLO.

6. 4 დისკის შევსება

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

ჰიპოთეზა: ლოგოების/კვოტების/ალერტების როტაცია იმუშავებს მარშრუტების დეგრადაციამდე.

7) ექსპერიმენტები K8s- ის გარეთ

7. 1 Toxiproxy (ადგილობრივი/ინტეგრაცია)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTPFault (პერიმეტრი/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (იდეის მაგალითი)

ექსპერიმენტი „მოკვლა“ N% EC2- ს Auto Scaling Group- ში, ხელოვნურად გაზარდოს EBS ლიტერატურა, გამორთოს NAT-GW ერთ AZ- ში.
ჩამონტაჟებული გაჩერების კრიტერიუმები CloudWatch SLO მეტრიკის მიხედვით.

8) დაკვირვების მეტრიკა ქაოსის დროს

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
RED მოდელი კრიტიკულ მარშრუტებზე (Rate, Errors, Duration).
აუზები: p95 კავშირის მოლოდინი, utilization.
BD: lag რეპლიკა, ლოკი, P95 მოთხოვნის დრიფტი.
ქსელი: retransmits, RTT, dscp/ecn ქცევა.
ბიზნეს SLI: გარიგების წარმატება (ანაბრები/შემოწმება), დაბრუნების/შეცდომების%.
ტრეკერი: ნიმუშის ტრეისები (ექსპლარები), გამოშვების პრეზენტაციების კორელაცია.

9) ინტეგრაცია SLO/Error-budget- ით

დაგეგმეთ ექსპერიმენტები შეცდომების ბიუჯეტის ფარგლებში: ქაოსმა არ უნდა „დაანგრიოს“ კვარტალური მიზნები.
Burn-rate ალერტაა, როგორც ავტომატური კილ-სვიტჩი.
მოხსენებები: „რამდენი ბიუჯეტი დაიწვა“, „რა სახის გადახედვაა სახელმწიფო“.

10) თამაშის დღეები (სავარჯიშოები)

სცენარი: მოკლე ლეგენდა (მაგალითად, „რეგიონი-აღმოსავლეთი“), ინექციების ნაბიჯები, SLO მიზნები, როლი, დრო.
შეფასება: RTO/RPO ფაქტობრივი, კომუნიკაციების ხარისხი, runbook- ის სისწორე.
რეტრო: მფლობელებთან და ვადებთან გაუმჯობესების სია, დოკუმენტაციის განახლება/დაშბორდები.

11) ავტომატიზაცია და CI/CD

Smoke-chaos: მოკლე ტესტები staging- ზე თითოეული გამოშვების დროს (მაგალითად, 1 pod-kill + 200 ms delay თითო მარშრუტზე).
ღამის/ყოველკვირეული: უფრო მძიმე სცენარები (5-15 წუთი) მოხსენებით.
პრომო კარიბჭეები: თუ p95/შეცდომები> ბარიერი საკანში - ავტო-გამოტოვება.
საცავი ექსპერიმენტების კატალოგით (YAML + runbook + SLO-thresholds).

12) ანტი შაბლონები

„დაარღვიე პროდი მოაჯირის გარეშე“: არ არსებობს stop კრიტერიუმები, არ არსებობს რეალური ინციდენტის რისკი.
ერთჯერადი მოქმედება პროცესის ნაცვლად.
ქაოსი სტანდარტული სახელმწიფო გარეშე: უცნობია რა ითვლება წარმატებას/წარუმატებლად.
ჭარბი ჭრილობები - DDoS შეფერხების დროს.
ბიზნეს SLI- ს უგულებელყოფა: „ტექნიკური“ წარმატებები გადახდების/შეკვეთების წარუმატებლობის შემთხვევაში.
პოსტ-ანალიზის არარსებობა და გაუმჯობესების მფლობელები.

13) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

განსაზღვრეთ SLI სახელმწიფო (მომხმარებლის + ბიზნესი).
შეარჩიეთ ინსტრუმენტი (Chaos Mesh/Litmus/Toxiproxy/FIS).
აღწერეთ მოაჯირები: blast radius, stop კრიტერიუმები, ფანჯრები, როლები.

11-25 დღე

დაიწყეთ პირველი ექსპერიმენტები: pod-kill, 100-200 ms delay კრიტიკულ აფსიდზე, პაკეტების 1% -ში.
Burn-rate alerta- ს კონფიგურაცია, kill-switch- ის დაკავშირება stop კრიტერიუმებთან.
გაატარეთ პირველი თამაშის დღე, შეაგროვეთ რეტრო და ფიქსაცია.

26-45 დღე

დაამატეთ სკრიპტები AZ/დამოკიდებულების დონეზე (გარე PSP, BD-lag).
Nightly ქაოსის ავტომატიზაცია staging; მოამზადეთ „სეზონური“ სცენარები (მწვერვალები).
ექსპერიმენტების კატალოგი და რეგულარული სახელმძღვანელო მოხსენებები/SRE.

14) სიმწიფის მეტრიკა

კრიტიკული მარშრუტების 80% -ზე მეტს აქვს აღწერილი ექსპერიმენტები და სახელმწიფო მეტრიკა.
Auto kill-switch მოქმედებს p99/error-rate- ის ბარიერების გადაჭარბებით.
კვარტალურად - AZ/რეგიონის დონის თამაშის დღე; 1 ჯერ/თვე - დამოკიდებულების მიზნობრივი სცენარი.
MTTR მცირდება გაუმჯობესების ციკლის შემდეგ, კორელაცია „გამოშვება - ინციდენტი“ მცირდება.
„მოულოდნელი“ ვარდნის წილი რეალურ წარუმატებლობებში ნულის ტოლია.
დაშბორდები აჩვენებენ „სტაბილურობას“, როგორც KPI (აღდგენის დრო, წარმატებული DR მოქმედებების წილი).

15) guardrails და stop გამომწვევების მაგალითები

Stop: 'http _ req _ failed> 1%' 3 წუთი, 'p99> 1000 ms' 3 ფანჯარა, 'deposit _ success <99. 5%`.
Blast radius- ის შემცირება: მანიფესტის მანქანის გამოტოვება, GSLB წონის დაბრუნება, fault ინექციების გამორთვა.
Stop ბრძანება: ერთი ღილაკი/სკრიპტი მიზეზების ანალიზით.

16) კულტურა და პროცესები

ქაოსი SRE რიტმის ნაწილია, არა ექსტრემალური.
გამჭვირვალე მოხსენებები, დაუცველების აღიარება, კორექტირების მოქმედებები.
On-call- ის ტრენინგი, მომხმარებლებთან/პარტნიორებთან კომუნიკაციის სიმულაცია.
დაკავშირება SLA/SLO- სთან და ბიუჯეტებთან: ქაოსმა უნდა გაზარდოს და არ შეაფერხოს საიმედოობა.

17) დასკვნა

Chaos Engineering „ცხრა იმედს“ მტკიცე სტაბილურობად აქცევს. ჩამოაყალიბეთ steady state, დააყენეთ მოაჯირი, დაარღვიეთ მცირე და კონტროლირებადი, დააკვირდით SLO და ბიზნეს SLI, დააფიქსირეთ და ავტომატიზირეთ გაუმჯობესება. შემდეგ რეალური გაუმართაობა გახდება კონტროლირებადი მოვლენები: პროგნოზირებადი RTO, დაცული error-budget და გუნდის მზადყოფნა იმოქმედოს პანიკის გარეშე.