სტაბილურობის ტესტირება

1) ძირითადი ცნებები და მიზნები

საიმედოობა (საიმედოობა) - მუშაობის ალბათობა; სტაბილურობა (გამძლეობა) - ქცევა გაუმართაობის დროს და მის შემდეგ.
SLO/მცდარი ბიუჯეტი: დეგრადაციის „მისაღები“ კრიტერიუმები.
Steady-state hypothesis: სტაბილური მეტრიკის ოფიციალური მოლოდინი (მაგალითად, p95 <200 ms, error rate <0). 5%). ექსპერიმენტი წარმატებულად ითვლება, თუ ჰიპოთეზა შენარჩუნებულია.
წარუმატებლობის ტიპები: ქსელის (ლატენტობა, დანაკარგები/დუბლები, შესვენება), გამოთვლები (CPU, მეხსიერება), სორტირება (I/O, დისკის ამოწურვა), დამოკიდებულება (5xx, timeouts, rate-limit), ლოგიკური (ნაწილობრივი ინციდენტები, „ნელი დეგრადაპტაცია“), ოპერაციული (გამოშვება, „),“ (split-brain, საათის ცვლა).

2) სტაბილურობის პირამიდა

1. ლოგიკის წარუმატებლობის ერთეულის ტესტები (რეტრაები, იდემპოტენტობა, ტაიმაუტები).
2. კომპონენტი Fault-inx- ით (Testcontainers/tc-netem).
3. ინტეგრაცია/სისტემა ქსელთან/BD/ქეშით და რეალურ სამყაროში პროფილებით.
4. ქაოსი ექსპერიმენტები pre-streat- ში (და შემდეგ შეზღუდულია გაყიდვაში) runbook- ის მიხედვით.
5. Game Day არის გუნდის სცენარის სავარჯიშოები (ხალხი + ინსტრუმენტები).

3) დაკვირვება, როგორც საფუძველი

SLI: ლატენტობა p50/p95/p99, error rate, saturation (CPU/heap/FD/IOPS), drop/timeout, queue depth.
ტრეკები: „ვიწრო ადგილების“ ძებნა მარცხის ქვეშ.
სემანტიკური სტაბილურობის მეტრიკა: წარმატებული graceful-degrade- ის წილი, დაშლილი მოთხოვნების წილი, თვითგანადგურების სიჩქარე (MTTR).
ექსპერიმენტების ეტიკეტირება: 'chaos. experiment _ id ',' phase = inject/recover 'მოვლენებში/ლოგოებში.

4) წარუმატებლობის ინექციების კატალოგი (faults)

ქსელი: შეფერხება/ჯიტერი, ზარალი/დუბლიკატები/განმეორება, გამტარუნარიანობის შეზღუდვა, პაკეტის „ქარიშხალი“, TLS კლდეები.
მასპინძელი: CPU შეზღუდვა, მეხსიერების გაჟონვა/ლიმიტები, GC პაუზები, აღწერილობების ამოწურვა, „clock skew“.
საცავი: ლატენტობის ზრდა, EROFS, ENOSPC, რეპლიკის დეგრადაცია, ლიდერის დაკარგვა.
დამოკიდებულებები: 5xx/429, შენელება, flapping DNS, მოძველებული სერთიფიკატები, rate-limit, „ნაწილობრივი პასუხები“.
მონაცემები: ჩანაწერის დაზიანება, ნაკადებში „ხვრელები“, მოვლენების დუბლირება, ვერსიების კონფლიქტი.
ოპერაციები: წარუმატებელი გამოშვება, ფიგურის დროშა, კონფისკაციის დრიფტი, სახელმძღვანელო შეცდომა (როგორც სიმულაციის ნაწილი).

5) სტაბილურობის ნიმუშები (შესამოწმებლად)

Retrai ერთად jitter და Timauts თითოეულ RPC- ზე.
Circuit Breaker (აღმოჩენა/ნახევრად თავშესაფარი, ექსპონენციალური აღდგენა).
Bulkheads (ტყვიების/რიგების იზოლაცია კრიტიკულ დომენებზე).
Load Shedding (ჩვენ ვაძლევთ დაბალი პრიორიტეტული მოთხოვნების გაჯერებას).
Backpressure (სიგნალები ჯაჭვის გასწვრივ, პარალელიზმის ლიმიტები).
Idempotence (იდემპოტენტურობის გასაღებები „გვერდითი მოვლენებზე“).
კეშინგი და სტაბილურობა წყაროს დეგრადაციის შემთხვევაში.
Graceful Degradation (მსუბუქი პასუხები, stale მონაცემები, fick გამორთვა).
Timeout-budget (მთლიანი ბიუჯეტი ზარის ჯაჭვზე).
ატომური/კომპენსაცია (Saga/Outbox/Transactional Inbox).
კვორუმი და რეპლიკაცია (R/W კვორუმი, თანმიმდევრულობის დეგრადაცია ხელმისაწვდომობისთვის).
Anti-entropy/raples (აღდგენა მოვლენების „ხვრელებში“).

6) ინექციებისა და მოლოდინების რეცეპტები (ფსევდოკოდი)

Retray ერთად jitter და braker

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

Shading და backpresher

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

Idempotenty

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7) ექსპერიმენტები: სცენარები და ჰიპოთეზები

7. 1 „ნელი დამოკიდებულება“

ინექცია: + 400 ms p95 გარე API- სთვის.
მოლოდინი: ტაიმაუტების ზრდა - X%, შესვენების გახსნა, fallback პასუხები, p99 სერვისის შენარჩუნება <SLA, ჭიდაობის დროს კასკადის არარსებობა.

7. 2 „ქეშის ნაწილობრივი დაკარგვა“

ინექცია: 50% Redis/Kash Shard კვანძების უკმარისობა.
მოლოდინი: გაზრდილი miss, მაგრამ ზვავის გარეშე წყაროსკენ (request coalescing/imutable TTL), მანქანის გათბობა და აღდგენა.

7. 3 „Split-brain BD“

ინექცია: ლიდერის დაკარგვა, რეპლიკზე გადასვლა.
ლოდინი: მოკლევადიანი ჩანაწერები, წაიკითხეთ კვორუმიდან, მონაცემთა დაკარგვის ნაკლებობა, Outbox არ კარგავს შეტყობინებებს.

7. 4 „ENOSPC/დისკი სავსეა“

ინექცია: დისკი 95-100% -ით.
ლოდინი: ლოგების გადაუდებელი როტაცია, ბლოკირების შეცდომების უარყოფა, კრიტიკული ჟურნალების უსაფრთხოება (WAL), ალერტები და ავტოლიკვიდი.

7. 5 „ტრაფიკის ბურსტი“

ინექცია: × 3 RPS ცხელი ენდოინტამდე 10 წთ

მოლოდინი: დაბალი პრიორიტეტის შეინინგი, სტაბილური p95 „ბირთვული“ ტრასებისთვის, ხაზების ზრდა ლიმიტებში, DLQ ქარიშხლების არარსებობა.

7. 6 «Clock Skew»

ინექცია: ნოდის დროის გადაადგილება +/− 2.
მოლოდინი: სწორი TTL/ხელმოწერები (leeway), მონოტონური ტაიმერები გამოსვლებში, მისაღები ნიშნები დასაშვები დრიფტით.

8) ექსპერიმენტების გარემო და უსაფრთხოება

დაიწყეთ pre-bird, სინთეზური მონაცემები, რაც შეიძლება ახლოს კონფიგურაციის/ტოპოლოგიის გაყიდვასთან.
გაყიდვაში - მხოლოდ კონტროლირებადი ფანჯრები, ფიგურის დროშები, ეტაპობრივი ამპლიტუდა, მანქანის გამოტოვება, „წითელი ღილაკი“.
Guardrails: RPS/შეცდომების ლიმიტები, SLO მცველები, გამოცემების ბლოკირება კრიტიკული ინციდენტების დროს.
სავალდებულოა runbook: როგორ უნდა გამოტოვოთ, ვის უნდა დაურეკოთ, სად უნდა უყუროთ.

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

ექსპერიმენტების კატალოგი, როგორც კოდი (YAML/DSL): მიზნები, ინექციები, მეტრიკა, ბარიერები, გამოტოვების „ღილაკები“.
Smoke-chaos თითოეულ გამოშვებაში: მოკლე ინექციები (მაგალითად, 2 წთ + 200 ms დამოკიდებულებით) სტეჯში.
მატრიქსის ღამის ღეროები: სერვისები × ტიპის წარუმატებლობები.
განთავისუფლების კარიბჭე: ზედმეტი აკრძალვა, თუ სტაბილურობა უფრო დაბალია, ვიდრე ზღურბლზე (მაგალითად, „fallback coverage <95%“ „ნელი დამოკიდებულების“ ქვეშ).

10) მონაცემები და თანმიმდევრულობა

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

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

შეამოწმეთ მხოლოდ happy-path და დატვირთვა წარუმატებლობის გარეშე.
Retrai გარეშე jitter - ქარიშხალი დეგრადაციის ქვეშ.
გლობალური ტაიმუტის ბიუჯეტის არარსებობა კასკადის ტაიმაუტებია.
ყველა ამოცანის ერთი აუზი არის იზოლაციის არარსებობა.
„გაუთავებელი“ ხაზები - ლატენტობის ზრდა/OOM.
ექსპერიმენტების ნულოვანი ტელემეტრია არის „ბრმა“ ქაოსის პრაქტიკა.
გაყიდვების ქაოსი საპასუხო/ლიმიტების/პასუხისმგებელი მფლობელის გარეშე.

12) არქიტექტორის ჩეკის სია

1. განსაზღვრულია სახელმწიფო ჰიპოთეზა და SLO?
2. თითოეულ RPC- ს აქვს ტაიმაუტები, ჯიტერი, ბრეიკერები?
3. განხორციელდა bulkheads, limiters, backpressure, load-shedding?
4. ქეში სტაბილურია: coalescing, დაცვა ქეშისგან, დათბობა?
5. Outbox/Saga გვერდითი მოვლენებისთვის, idempotent გასაღებები?
6. ტესტირება ხდება კვორუმი/რეპლიკაცია/ფეილოვერი?
7. არსებობს ექსპერიმენტების კატალოგი, nightly ქაოსი და კარიბჭეები CI/CD- ში?
8. მეტრიკი/ტრეკები აღნიშნავენ ექსპერიმენტებს, არის დაშბორდები?
9. მზად არის Runbook 'და წითელი ღილაკი, პასუხისმგებლობა ენიჭება?
10. რეგულარული თამაში Dev/SRE/Support მონაწილეობით?

13) მინი ინსტრუმენტები და სკრიპტების მაგალითები (YAML ესკიზები)

ქსელი (tc/netem)

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

CPU/Heap

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

დამოკიდებულება

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

დასკვნა

სტაბილურობის ტესტირება არ არის „ქაოსის ხრიკი“, არამედ დისციპლინა, რომელიც სისტემას პროგნოზირებს წარუმატებლობის ქვეშ. მკაფიო ჰიპოთეზები, ტელემეტრია, კონტროლირებადი ექსპერიმენტების კატალოგი და არქიტექტურაში ჩასმული ნიმუშები (ტაიმაუტები, ბრეიკერები, იზოლაცია, იდემპოტენტობა) პოტენციურ ინციდენტებს კონტროლირებად სცენარებად აქცევს. გუნდი იღებს ნდობას რელიზებში, ხოლო მომხმარებლები სტაბილური მომსახურებით, თუნდაც უარის თქმის პირობებში.