Mécanismes de contrôle de santé

1) Pourquoi

Health-checks est la première barrière contre les pannes en cascade : ils retirent correctement les nœuds de la rotation, évitent les tempêtes de rétraction, simplifient la dégradation et accélèrent la récupération, en conservant le SLO et en réduisant le MTTR.

2) Types de contrôle de base

Liveness est un processus « vivant » (pas de deadlock/fuite/panique). Erreur → le restart de l'instance.
Le service est capable de servir le trafic avec les SLO cibles (pools levés, cache chauffé, ressources dépendantes normales). L'erreur → être exclue de l'équilibrage, mais pas restaurée.
Startup - le service est prêt à passer à liveness/read....( long bootstrap, migration, warmup). Protège contre les restaurateurs prématurés.
Deep-health (domaine spécifique) : invariants d'affaires (le taux passe de bout en bout, le dépôt est autorisé par le PSP actif). Ils sont utilisés pour les signaux de dégradation, mais pas pour le restart immédiat.
External/Synthetic : Pings actifs à l'extérieur (chemin API, front-script, PSP/KYC endpoint) - mesurer la disponibilité de l'utilisateur.

3) Conception d'échantillons : règles générales

1. Liveness bon marché : nous n'allons pas dans les dépendances extérieures ; on vérifie la boucle des événements, heap/FD, watchdog.
2. Lecture par SLO : Vérifiez les ressources locales nécessaires à la maintenance (pools OBD, cache chaud, limites). Dépendances externes - par le biais de « can-serve » non bloquants ? signaux.
3. Latency-budget : chaque essai a свой SLA (par exemple, ≤100-200 мс); en cas de dépassement, « degraded », mais pas 5xx par liveness.
4. Backoff & Jitter : intervalles d'échantillonnage de 5 à 15 secondes, temps d'attente de 1 à 2 secondes, avec un retard exponentiel sur les erreurs pour éviter les tempêtes synchrones.
5. Hystérésis : N réponses réussies/erronées pour le changement de statut (par exemple, 'successThreshold = 2', 'failureThreshold = 3').
6. Versionation : les endpoints '/healthz ', '/readyz', '/startupz 'sont stables ; deep-checks sous '/health/... 'avec contrôles nommés.
7. Sans secret et PII : les réponses ne sont que des statuts et des codes courts.
8. Explainability : JSON avec une liste de sous-vérifications : '{"status" : "degraded", "checks" : [{"name" : "db", ok ": true", latencyMs' : 18}, {"name" : "psp. eu","ok":false,"reason":"timeout"}]}`.

4) Exemples deep-checks par couches

4. 1 système OBD/cache/stockage

OBD : courte transaction 'SELECT 1' par réplique de lecture et vérification du pool ; seuils de latence/replication-lag.
Cache : 'GET '/' SET' de la clé de test + hit-ratio guard (bas hit → warning).
Stockage d'objets : HEAD d'un objet existant (non téléchargé).

4. 2 Files d'attente/streaming

Courtier : ping-topic public + consume dans la partition locale ; seuils de consommation-lag.
DLQ : Pas de sursaut de messages dans le dead-letter par la fenêtre.

4. 3 Fournisseurs externes (PSP/KYC/AML)

PSP : lightweight auth-probe (non monetary), vérification des contrats/certificats/quotas ; s'il n'y a pas d'échantillons de sécurité - utiliser des mesures par procuration (succès des autorisations en 5 à 10 min par banque/GEO).
KYC/AML : API santé et file d'attente SLA ; en cas de dégradation, passer à un autre flux/fournisseur.

4. 4 API/front

Synthétique : chemin transactionnel (login → dépôt-initiation → pari « dans le sable ») dans l'UE/LATAM/APAC.
Signal RUM : proportion d'erreurs JS/HTTP et LCP/TTFB - déclencheurs « extérieurs ».

5) Intégration avec la plate-forme

5. 1 Kubernetes / Cloud

'startupProbe' protège le bootstrap (migration/cache-warmup).
'livenessProbe' est minimaliste ; 'read....@@Probe' tient compte des pools/cache/files d'attente locales.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisruptionBudget et maxUnavailable en tenant compte de la lecture.
HPA/KEDA : mise à l'échelle des files d'attente/SLI ; read....affecte le routing.

5. 2 Équilibreurs/passerelles/mesh

Routing de santé au niveau L7 (HTTP 200/429/503 semantics).
Outlier detection (envoy/mesh) : sortie du pool par error-rate/latency percentiles.
Circuit-breaker : limites des demandes simultanées/connexions de dépendance, intégration avec les signaux de santé.

5. 3 Auto-skating et dégradation

Read....= FAUX → le trafic est filmé, mais le pod est vivant (peut se réchauffer).
Deep-degrade (PSP down) → la fonctionnalité flags pour le mode graceful (par exemple, masquer temporairement les méthodes de paiement, activer waiting-room).

6) Politiques de temporisation et de rétractation

Temporisation <budget SLO : 'timeout = min (⅓ p99, 1-2s)' pour les dépendances synchrones.
Idempotence : obligatoire pour les rétrogras ; on utilise les idempotency-keys.
Backoff exponentiel + jitter : empêche les effets d'arbre synchrones.
Budgets rétroactifs : caps per-request/tenant, protection contre les « retry-storms ».

7) Signaux d'état et alerting

Vert/Jaune/Rouge : statuts consolidés pour le service dashboard.
Burn-rate-alerts par SLO : rapides (1 h) et lents (6-24 h).
Correlation-hints : notes de sortie/drapeaux de fich/travaux de planification.
Auto-actions : avec le deep-check « rouge » - activer le fournisseur fallback, augmenter l'échantillonnage des pistes.

8) Stratégies intelligentes pour iGaming

Payment-aware read....: la disponibilité du service de paris tient compte de l'état du routeur PSP et des limites par banque/GEO.
Odds/Lines publishing : read....chez le pablisher dépend de l'ensemble des sources de ligne et du temps de distribution dans le cache/edge.
Tournament spikes : une politique temporelle plus agressive outlier-detection et waiting-room.

9) Anti-modèles

Liveness, qui va à la base de données/PSP → des restarts de masse pour un problème externe.
Un endpoint santé « polyvalent » sans séparation startup/read..../liveness.
Temps d'attente durs sans backoff/jitter → tempête de retraits.
Absence d'hystérésis → flapping de routage.
Deep-check, qui déclenchera les restarts (son objectif est le diagnostic et le routage, pas le redémarrage).
5xx cachés dans les endpoints de santé (masquage du statut réel).

10) Modèles d'interfaces

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

Vérifications : les scripts init, les migrations terminées, les clés et les configs chargés.

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

Vérifications : cycle d'événements, ressources de processus, pas de panique/drapeaux 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) Indicateurs de qualité du circuit de santé (KPI/KRI)

Heure de sortie du pod de « NotReady » dans « Ready » (warmup-SLO).
Fréquence « flapping » read....per service.
% de pod restitués par erreur (root-cause est une dépendance externe).
Les incidents MTTR où les mécanismes de santé ont joué un rôle (avant/après).
Part de failover automatique/feature-degrade sans intervention sur appel.
Précision des synthétiques vs RUM (faux positifs/omissions).

12) Feuille de route pour la mise en œuvre (4-8 semaines)

Ned. 1-2 : inventaire des voies critiques ; dissocier startup/liveness/read....; entrez les réponses JSON avec les sous-vérifications et l'hystérésis.
Ned. 3-4 : ajouter deep-checks : OBD/cache/courtier ; synthétique pour login/dépôt/taux dans 2-3 GEO ; activer outlier-detection dans la passerelle/mesh.
Ned. 5–6: payment-aware readiness и PSP-fallback; waiting-room pour le front ; Auto-skating par lag/files d'attente ; alertes par burn-rate.
Ned. 7-8 : jours de chaos (désactivation de PSP/répliques OBD), vérification backoff/jitter ; Fintuning des temporisations, PDB ; Rapport KPI et ajustement.

13) Artefacts

Spec Santé (per service) : liste des contrôles, budgets temps, hystérésis, actions au statut rouge.
Runbooks : "Read....= FAUX : que faisons-nous ? ", "PSP-fallback : étapes et critères de retour".
Politique de routage : règles outlier-detection, circuits-breakers, seuils percentiels.
Synthetic Playbook : scripts et géographies, SLO synthétiques, planning.
Release Gate : blocs de release en rouge deep-check des dépendances clés.

Total

Une boucle health-checks bien conçue est un système de signaux en couches : liveness facile pour la viabilité du processus, read....pour la capacité à servir le trafic, startup pour le démarrage sécurisé et deep-checks spécifiques au domaine pour la dégradation et le routage gérés. Associé à l'autoscaling, à l'outlier-routing, à la synthétique et au SLO-alerting, il réduit le risque de défaillances en cascade, réduit le MTTR et stabilise les parcours critiques de la plate-forme iGaming.