Sağlamlıq-yoxlama mexanizmləri
1) Niyə
Health-checks kaskad uğursuzluqlara qarşı ilk maneədir: onlar düzgün rotasiya qovşaqlarını çıxarır, retraj fırtınalarının qarşısını alır, deqradasiyanı asanlaşdırır və bərpa sürətləndirir, SLO saxlayır və MTTR-i azaldır.
2) Əsas yoxlama növləri
Liveness - «canlı» prosesi (heç bir deadlock/sızma/panika). Səhv → nüsxəni yenidən başlatmaq.
Readiness - xidmət hədəf SLO ilə trafikə xidmət edə bilər (hovuzlar qaldırılır, cache isitmə, normal asılı resurslar). Səhv → balansdan çıxarmaq, lakin yenidən başlamamaq.
Startup - Xidmət liveness/readiness (uzun bootstrap, miqrasiya, warmup) keçməyə hazırdır. Vaxtından əvvəl restartlardan qoruyur.
Deep-health (domen-spesifik): biznes invariantları (bahis end-to-end keçir, depozit aktiv PSP-yə verilir). Deqradasiya siqnalları üçün istifadə olunur, lakin dərhal yenidən başlamaq üçün deyil.
External/Synthetic: Xaricdə aktiv pinqlər (API yolu, ön skript, PSP/KYC end point) - istifadəçi əlçatanlığını ölçün.
3) Nümunə dizaynı: ümumi qaydalar
1. Ucuz həyat: xarici asılılığa getmirik; hadisə döngəsini, heap/FD, watchdog yoxlayın.
2. SLO ilə Readiness: xidmət üçün lazım olan yerli resursları yoxlayın (DB hovuzları, isti cache, limitlər). Xarici asılılıqlar - bloklanmayan «can-serve?» siqnallar.
3. Latency-budget: hər nümunə öz SLA var (məsələn, ≤ 100-200 ms); aşdıqda - «degraded», lakin 5xx liveness.
4. Backoff & Jitter: sınaq intervalları 5-15 saniyə, zaman aşımı 1-2 saniyə, sinxron fırtınanın qarşısını almaq üçün səhvlərdə eksponensial gecikmə ilə.
5. Histeresis: Status dəyişikliyi üçün N uğurlu/səhv cavab (məsələn, 'successThreshold = 2', 'failureThreshold = 3').
6. Versiyalaşdırma: end nöqtələri '/healthz ', '/readyz', '/startupz 'sabitdir; deep-checks altında '/health/... 'adlandırılmış yoxlamalar ilə.
7. Gizli və PII olmadan: cavablar yalnız status və qısa kodlardır.
8. Explainability: JSON alt yoxlamalar siyahısı ilə: '{"status ": "degraded "", checks ": [{"name ": "db"", ok": true", latencyMs": 18}, {" name":" psp. eu","ok":false,"reason":"timeout"}]}`.
4) Qatlara görə deep-checks nümunələri
4. 1 DB/cache/saxlama
BD: «SELECT 1» qısa əməliyyat read-replika və hovuz yoxlama; latency/replication-lag eşik.
Cache: 'GET '/' SET' test açarı + hit-ratio guard (aşağı hit → warning).
Object Storage: Mövcud obyektin HEAD (yükləmədən).
4. 2 Növbələr/axın
Broker: yerli partition daxilində ping-topic publish + consume; consumer-lag eşik.
DLQ: Pəncərə arxasında dead-letter mesajları yoxdur.
4. 3 Xarici provayderlər (PSP/KYC/AML)
PSP: lightweight auth-probe (qeyri-monetary), müqavilə/sertifikat/kvota yoxlama; safe-nümunələr yoxdursa, proksi-metrikadan istifadə edirik (banklarda/GEO-da 5-10 dəq ərzində avtorizasiyaların uğuru).
KYC/AML: sağlamlıq-API və SLA növbələri; deqradasiya zamanı - alternativ axına/provayderə keçid.
4. 4 API/cəbhə
Sintetika: əməliyyat yolu (giriş → depozit-başlanğıc → «qum» bahis) AB/LATAM/APAC.
RUM siqnalı: JS/HTTP və LCP/TTFB səhvlərinin payı «xaricdə» tetikləyicilərdir.
5) Platforma ilə inteqrasiya
5. 1 Kubernetes / Cloud
'startupProbe' bootstrap (miqrasiya/cache warmup) qoruyur.
'livenessProbe' minimalist; 'readinessProbe' hovuzları/cache/lokal növbələri nəzərə alır.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisruptionBudget və maxUnavailable readiness nəzərə alınmaqla.
HPA/KEDA: növbə/SLI; readiness routing təsir edir.
5. 2 Balans/şlüzlər/mesh
L7 (HTTP 200/429/503 semantics) səviyyəsində sağlamlıq-routing.
Outlier detection (envoy/mesh): puldan error-rate/latency üzlükləri ilə çıxarılması.
Circuit-breaker: asılılıq üçün eyni vaxtda sorğu/qoşulma limitləri, sağlamlıq siqnalları ilə inteqrasiya.
5. 3 Avtoskeylinq və deqradasiya
Readiness = FALSE → trafik aradan qaldırılır, lakin pod sağ (isti ola bilər).
Deep-degrade (PSP down) → graceful rejimi üçün feature flags (məsələn, ödəniş metodlarını müvəqqəti gizlətmək, waiting-room daxil).
6) Time-out və retraj siyasəti
Zaman aşımı <SLO büdcəsi: 'timeout = min (⅓ p99, 1-2s)' sinxron asılılıqlar üçün.
İdempotentlik: retrajlar üçün məcburidir; idempotency-keys istifadə.
Eksponensial backoff + jitter: sinxron val effektlərinin qarşısını alır.
Retraj büdcələri: caps per-request/tenant, «retry-storms» qorunması.
7) Vəziyyət siqnalları və alertinq
Yaşıl/Sarı/Qırmızı: xidmət daşbordunda birləşdirilmiş statuslar.
SLO üzrə Burn-rate-alertlər: sürətli (1 saat) və yavaş (6-24 saat).
Correlation-hints: buraxılışlar/fich bayraqları/planlı işlər haqqında qeydlər.
Auto-actions: «qırmızı» deep-check ilə - fallback provayderi işə salmaq, trass sampling artırmaq.
8) iGaming üçün ağıllı strategiyalar
Payment-aware readiness: bahis xidmətinin hazırlığı PSP marşrutlaşdırıcısının vəziyyətini və banklar/GEO limitlərini nəzərə alır.
Odds/Lines publishing: publisher-də readiness/edge cache-də lines mənbələri və paylanma vaxtı ilə birləşdirilmiş lag asılıdır.
Tournament spikes: müvəqqəti siyasət daha aqressiv outlier-detection və waiting-room.
9) Antipattern
DB/PSP gedir Liveness → xarici problem kütləvi restarts.
Startup/readiness/liveness ayrılmadan bir «universal» sağlamlıq nöqtəsi.
Backoff/jitter → fırtına retrains olmadan sərt vaxt.
Histerezis → flapping marşrutlaşdırma yoxdur.
Restartları tetikləyən Deep-check (məqsədi diaqnostika və marşrutlaşdırmadır).
Sağlamlıq nöqtələrində gizli 5xx (real status maskası).
10) Interfeys şablonları
/startupz → `200 OK {"uptimeSec": ..., "version":"..."}`
Yoxlamalar: init skriptləri, miqrasiyalar tamamlandı, açarlar və konfiqlər yükləndi.
/healthz (liveness) → `200 OK {"heapOk": true,"fdOk":true,"eventLoop":"ok"}`
Yoxlamalar: hadisələr dövrü, proses resursları, heç bir çaxnaşma/oom bayraqları.
/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) Sağlamlıq konturunun keyfiyyət göstəriciləri (KPI/KRI)
Pod-un 'NotReady' -dən 'Ready' -ə (warmup-SLO) çıxma vaxtı.
Tezlik «flapping» readiness per xidmət.
% səhvən yenidən qurulmuş pod (root-cause - xarici asılılıq).
MTTR hadisələr, harada sağlamlıq mexanizmləri rol oynadı (əvvəl/sonra).
On-call iştirakı olmadan avtomatik failover/feature-degrade payı.
Sintetikanın dəqiqliyi vs RUM (saxta pozuntular/boşluqlar).
12) Yol xəritəsi (4-8 həftə)
Ned. 1-2: kritik yolların inventarlaşdırılması; startup/liveness/readiness yaymaq; JSON cavabları alt yoxlamalar və histerezis daxil edin.
Ned. 3-4: deep-checks əlavə edin: BD/cache/broker; 2-3 GEO-da login/depozit/bahis üçün sintetika; şlüzdə outlier-detection daxil/mesh.
Ned. 5–6: payment-aware readiness и PSP-fallback; ön üçün waiting-room; lag/növbələr üzrə avtoskeylinq; burn-rate üzrə alertlər.
Ned. 7-8: chaos-gün (PSP/DB replica devre dışı), backoff/jitter yoxlama; fintyuning time-out, PDB; KPI hesabatı və düzəliş.
13) Artefaktlar
Health Spec (per xidmət): yoxlamalar siyahısı, vaxt büdcələri, histerezis, qırmızı statuslu hərəkətlər.
Runbooks: "Readiness = FALSE: nə edirik? ", "PSP-fallback: addımlar və geri dönüş meyarları".
Routing Policy: outlier-detection qaydaları, circuit-breakers, üzlük astanaları.
Synthetic Playbook: ssenari və coğrafiya, SLO sintetik, cədvəl.
Release Gate: Qırmızı deep-check əsas asılılıqlarda buraxılış blokları.
Yekun
Yaxşı dizayn edilmiş sağlamlıq-yoxlama konturu laylı siqnal sistemidir: prosesin canlılığı üçün yüngül həyat, trafikə xidmət etmək qabiliyyəti üçün readiness, təhlükəsiz başlanğıc üçün başlanğıc və idarə olunan deep-yoxlama və marşrutlaşdırma üçün domen xüsusi deep-yoxlamaları. Autoscaling, outlier-routing, sintetika və SLO-alerting ilə birlikdə kaskad uğursuzluq riskini azaldır, MTTR-ni azaldır və iGaming platformasının iş üçün kritik yollarını sabitləşdirir.