ჯანმრთელობის შემოწმების მექანიზმები

1) რატომ

ჯანმრთელობის შემოწმებები პირველი ბარიერია კასკადის უკმარისობის წინააღმდეგ: ისინი სწორად ამოიღებენ კვანძებს როტაციიდან, ხელს უშლიან ქარიშხლის ქარიშხალს, ამარტივებენ დეგრადაციას და აჩქარებენ აღდგენას, ინარჩუნებენ SLO- ს და ამცირებენ MTTR- ს.

2) ძირითადი ტიპის შემოწმება

Liveness - პროცესი „ცოცხალი“ (არ არსებობს deadlock/გაჟონვა/პანიკა). ინსტალაციის გადატვირთვის შეცდომა.
Readiness - სერვისს შეუძლია მოემსახუროს ტრაფიკი მიზნობრივი SLO- ით (გაიზარდა აუზები, ქეში გაათბეთ, დამოკიდებულ რესურსებს ნორმალურად). შეცდომა შეიძლება გამოირიცხოს დაბალანსებისგან, მაგრამ არა გადატვირთვა.
Startup - სერვისი მზად არის გადავიდეს liveness/readiness (გრძელი bootstrap, მიგრაცია, warmup). იცავს ნაადრევი გადატვირთვებისგან.
Deep-health (დომენის სპეციფიკური): ბიზნეს ინვარიანტები (განაკვეთი გადის end-to-end, ანაბარი ავტორიზებულია აქტიური PSP- სგან). ისინი გამოიყენება დეგრადაციის სიგნალებისთვის, მაგრამ არა დაუყოვნებლივი აღდგენისთვის.
External/Synthetic: აქტიური პინგები გარეთ (API გზა, წინა სკრიპტი, PSP/KYC endpoint) - იზომება მომხმარებლის წვდომა.

3) ნიმუშების დიზაინი: ზოგადი წესები

1. იაფი ცხოვრება: ჩვენ არ მივდივართ გარე დამოკიდებულებაში; ჩვენ ვამოწმებთ მოვლენების მარყუჟს, heap/FD, watchdog.
2. რეალობა SLO- სთვის: ჩვენ ვამოწმებთ მომსახურებისთვის საჭირო ადგილობრივ რესურსებს (BD აუზები, თბილი ქეში, ლიმიტები). გარე დამოკიდებულება - არა ბლოკირების „can-serve?“ სიგნალები.
3. Latency-budget: თითოეულ ნიმუშს აქვს საკუთარი SLA (მაგალითად, 100-200 ms); ზედმეტი - „degraded“, მაგრამ არა 5xx liveness.
4. Backoff & Jitter: ნიმუშების ინტერვალები 5-15 წამი, დრო 1-2 წამი, ექსპონენციალური შეფერხება შეცდომების დროს, სინქრონული ქარიშხლის თავიდან ასაცილებლად.
5. ჰისტერეზი: N წარმატებული/მცდარი პასუხები სტატუსის შეცვლისთვის (მაგალითად, 'successThreshold = 2', 'failueuleThreshold = 3').
6. ვერსია: ენდოინტები '/healthz ', '/readyz', '/startupz 'სტაბილურია; deep checks „/health/... “სახელწოდებით შემოწმებები.
7. საიდუმლო და PII: პასუხები მხოლოდ სტატუსები და მოკლე კოდებია.
8. Expainability: JSON, შემოწმების ჩამონათვალით: '{„status“: „degraded“ „, checks“: [{„name“: „db“, კარგი „: ნამდვილი“, latencyms „: 18}, {“ name „:“ psp. eu","ok":false,"reason":"timeout"}]}`.

4) დისპლეის შემოწმების მაგალითები ფენებში

4. 1 BD/ქეში/საცავი

BD: მოკლე გარიგება 'SELECT 1' რეპლიკზე და აუზის შემოწმება; latency/replication-lag ბარიერები.
ქეში: 'GET '/' SET' ტესტის გასაღები + hit-ratio guard (დაბალი hit-warning).
Object Storage: არსებული ობიექტის HEAD (გადმოტვირთვის გარეშე).

4. 2 რიგები/ნაკადი

ბროკერი: ping-topic publish + consume ადგილობრივი ნაწილების ფარგლებში; consumer-lag ბარიერები.
DLQ: ფანჯრის უკან dead-letter შეტყობინებების ნაკლებობა.

4. 3 გარე პროვაიდერები (PSP/KYC/AML)

PSP: lightweight auth-probe (არაკომერციული), ხელშეკრულების/სერტიფიკატის/კვოტის შემოწმება; თუ არ არსებობს safe ნიმუშები, ჩვენ ვიყენებთ მარიონეტულ მეტრებს (ავტორიზაციების წარმატება ბანკებისთვის 5-10 წუთში/GEO).
KYC/AML: health-API და SLA რიგები; დეგრადაციის დროს - ალტერნატიული ნაკადის/პროვაიდერის შეცვლა.

4. 4 API/ფრონტი

სინთეტიკა: გარიგების გზა (ლოგინი - სადეპოზიტო ინიცირება - განაკვეთი „ქვიშაში“) EU/LATAM/APAC.
RUM სიგნალი: შეცდომების წილი JS/HTTP და LCP/TTFB არის ტრიგერები „გარეთ“.

5) ინტეგრაცია პლატფორმასთან

5. 1 Kubernetes / Cloud

'startupProbe' იცავს bootstrap (მიგრაცია/ქეში-warmup).
'livenessprobe' მინიმალისტური; 'readesprobe' ითვალისწინებს აუზებს/ქეშებს/ადგილობრივ რიგებს.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisrupite Budget და maxUnavaillable, რეალობის გათვალისწინებით.
HPA/KEDA: რიგები/SLI; Reading გავლენას ახდენს routing- ზე.

5. 2 დაბალანსება/კარიბჭე/mesh

ჯანმრთელობა L7 დონეზე (HTTP 200/429/503 სემანტიკა).
Outlier detection (envoy/mesh): ტყვიისგან ამოღება error-rate/latency percentils.
Circuit-breaker: ერთდროული მოთხოვნების/დამოკიდებულების შეზღუდვები, ჯანმრთელობის სიგნალებთან ინტეგრაცია.

5. 3 ავტო სკეილინგი და დეგრადაცია

Readiness = FALSE - ტრეფიკი ამოღებულია, მაგრამ pod ცოცხალია (მას შეუძლია ათბობს).
Deep-degrade (PSP down) - feature flags graceful რეჟიმში (მაგალითად, დროებით დამალვა გადახდის მეთოდები, ჩართეთ waiting-room).

6) დროისა და რეაგირების პოლიტიკა

Time-out <SLO ბიუჯეტი: 'timeout = min (p99, 1-2s)' სინქრონული დამოკიდებულებისთვის.
Idempotence: სავალდებულოა retray- სთვის; ჩვენ ვიყენებთ idempotency-keys.
ექსპონენციალური backoff + jitter: ხელს უშლის სინქრონული ლილვის ეფექტებს.
Retry ბიუჯეტები: caps per-request/tenant, დაცვა „retry-storms“.

7) სახელმწიფო სიგნალები და ალერტინგი

მწვანე/ყვითელი/წითელი: კონსოლიდირებული სტატუსი დაშბორდის სერვისზე.
Burn-rate-alerts SLO: სწრაფი (1 საათი) და ნელი (6-24 საათი).
Correlation-hints: ნოტები გამოშვებების/fich დროშების/დაგეგმილი სამუშაოების შესახებ.
Auto actions: „Red“ deep-check- ით - ჩართეთ პროვაიდერი fallback, გაზარდეთ ბილიკების ნიმუშები.

8) ჭკვიანი სტრატეგიები iGaming- ისთვის

უსაფრთხოება: განაკვეთების სერვისის მზადყოფნა ითვალისწინებს PSP როუტერის მდგომარეობას და ბანკების/GEO შეზღუდვებს.
Odds/Lines publishing: Pablisher- ის რეალობა დამოკიდებულია ხაზების წყაროებსა და ქეში/edge- ში განაწილების დროზე.
Tournament spikes: დროებითი პოლიტიკა უფრო აგრესიული outlier detection და waiting-room.

9) ანტიპატერები

Liveness, რომელიც მიდის BD/PSP- ში, არის მასობრივი შეზღუდვები გარე პრობლემასთან დაკავშირებით.
ერთი „უნივერსალური“ ჯანმრთელობის ენდოინტი startup/readiness/liveness- ის განცალკევების გარეშე.
მძიმე დროის გადაღებები backoff/jitter- ის გარეშე არის ქარიშხალი.
ჰისტერეზის არარსებობა არის მარშრუტიზაციის ფუფუნება.
Deep-check, რომელიც გამოიწვევს რესტარტებს (მისი მიზანია დიაგნოზირება და მარშრუტიზაცია, არ გადატვირთვა).
ფარული 5xx health endpoints (რეალური სტატუსის შენიღბვა).

10) ინტერფეისის შაბლონები

/startupz → `200 OK {"uptimeSec": ..., "version":"..."}`

შემოწმებები: ინიტის სკრიპტები, მიგრაცია დასრულებულია, დატვირთულია გასაღებები და კონფისკაცია.

/healthz (liveness) → `200 OK {"heapOk": true,"fdOk":true,"eventLoop":"ok"}`

შემოწმებები: მოვლენების ციკლი, პროცესის რესურსები, პანიკის/oom დროშების არარსებობა.

/readyz (readiness) →

`200 OK/503 {"canServe": true,"db":{"ok":true,"latencyMs":12},"cache":{"ok":true},"queue":{"ok":true,"lag":0},"localQuota":{"ok":true}}`

/health/payments (deep) →

`200/206/503 {"psp. eu": {"ok":false,"reason":"timeout"}, "psp. alt":{"ok":true}, "routerMode":"failover"}`

11) ჯანმრთელობის მიკროსქემის ხარისხის მეტრიკა (KPI/KRI)

pod- ის გასვლის დრო 'NotReady' - დან 'Ready' - ში (warmup-SLO).
Flapping reading per სერვისის სიხშირე.
% შეცდომით რეგულირებული pod (root-cause - გარე დამოკიდებულება).
MTTR ინციდენტები, სადაც ჯანმრთელობის მექანიზმებმა როლი ითამაშეს (მანამდე/მის შემდეგ).
ავტომატური failover/feature-degrade- ის წილი on-call- ის მონაწილეობის გარეშე.
სინთეზის სიზუსტე vs RUM (ყალბი ექსპლუატაცია/გადასასვლელი).

12) განხორციელების გზის რუკა (4-8 კვირა)

ნვე. 1-2: კრიტიკული ბილიკების ინვენტარიზაცია; განაწილება startup/liveness/readiness; შემოიღეთ JSON პასუხები შემოწმებისა და ჰისტერეზის ქვეშ.
ნვე. 3-4: დაამატეთ deep-checks: BD/ქეში/ბროკერი; სინთეზური ლოგინი/დეპოზიტი/განაკვეთები 2-3 GEO; ჩართეთ outlier detection კარიბჭეში/mesh.
ნვე. 5–6: payment-aware readiness и PSP-fallback; წინა ოთახი; მანქანის სკეილინგი lag/რიგებში; ალერტები burn-rate.
ნვე. 7-8: chaos დღეები (გამორთვა PSP/BD რეპლიკები), backoff/jitter- ის შემოწმება; დროის დახარჯვა, PDB; KPI ანგარიში და კორექტირება.

13) არტეფაქტები

Health Spec (პერ სერვისი): შემოწმებების სია, დროის ბიუჯეტები, ჰისტესეზი, წითელი სტატუსის მქონე მოქმედებები.
Runbooks: "Readiness = FALSE: რას ვაკეთებთ? "", PSP-fallback: დაბრუნების ნაბიჯები და კრიტერიუმები".
Routing Policy: outlier detection წესები, circuit-breakers, percent ბარიერები.
სინთეზური თამაში: სკრიპტები და გეოგრაფიები, სინთეზური SLO, გრაფიკი.
Release Gate: განთავისუფლების ბლოკები ძირითადი დამოკიდებულების წითელი ღრმა შემოწმებით.

შედეგი

კომპეტენტურად შემუშავებული health შემოწმების წრე არის ფენიანი სიგნალის სისტემა: პროცესის სიცოცხლისუნარიანობის მსუბუქი ზღვარი, ტრაფიკის მომსახურების უნარის რეგულირება, უსაფრთხო დაწყების startup და დომენის სპეციფიკური deep-checks კონტროლირებადი დეგრადაციისა და მარშრუტიზაციისთვის. Autoscaling, outlier-routing, სინთეზური და SLO ალერტინგთან ერთად, იგი ამცირებს კასკადის უკმარისობის რისკს, ამცირებს MTTR- ს და სტაბილიზაციას უწევს iGaming პლატფორმის ბიზნეს კრიტიკულ გზებს.