Auto-guérison et auto-guérison

(Section : Technologie et infrastructure)

Résumé succinct

L'auto-guérison n'est pas la « magie de Kubernetes », mais un ensemble de disciplines : échantillons corrects et limites, retraits contrôlés, isolation des instances défectueuses, automatisation par SLO et action runabook par bouton/bot. L'objectif est de réduire MTTR sans « boule de neige » surcharge et de maintenir p95/p99, paiements et TTW même au sommet.

1) Principes d'auto-guérison

1. Fail-fast & isolate : identifiez et isolez rapidement les mauvais pods/instances.
2. Backoff + jitter : tout rétracteur/skale-out - avec un retard exponentiel et un jitter.
3. SLO-aware : l'automatisation est activée/renforcée avec un budget d'erreurs rapide.
4. Idempotency : la répétition des opérations est sécurisée (en particulier les paiements/files d'attente).
5. Defense in depth : échantillons, quotas, limites, circuit-breaker, outlier-ejection, rate-limit, mode dégradation.

2) Base à Kubernetes

2. 1 Échantillons : liveness/read..../startup

startupProbe protège contre les restaurations prématurées de services lourds.
read....@@Probe détermine la disponibilité au trafic (caches/connexions chauffées).
livenessProbe redémarre les processus « dépendants ».

yaml readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 3

livenessProbe:
httpGet: { path: /health/live, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3

startupProbe:
httpGet: { path: /health/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 30

2. 2 Limites, APB et priorités

les demandes/limites excluent « noisy neighbor ».
Le PodDisruptionBudget (PDB) empêche tous les pods de tomber simultanément.

yaml apiVersion: policy/v1 kind: PodDisruptionBudget spec:
minAvailable: 2 selector: { matchLabels: { app: payments-api } }

PriorityClass pour les chemins critiques (payments, gateway).

2. 3 Redémarrage et stratégie de dépliage

« maxUnavailable : 0 » pour les services critiques ; rollingUpdate à petit pas.
PodAntiAffinity distribue les pods aux nodules/zones.

3) Auto-skating et Evénement Scaling

HPA (CPU/métriques personnalisées)

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
minReplicas: 3 maxReplicas: 30 metrics:
- type: Resource resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
- type: Pods pods:
metric:
name: http_requests_per_second target:
type: AverageValue averageValue: "50"

VPA

Utiliser pour les workers d'arrière-plan/tâches par lots ; dans l'API prod - attention (redémarrez).

KEDA (files d'attente/événements externes)

Déclencheurs par Kafka lag, RabbitMQ, Redis, Prometheus - augmenter les consommateurs lorsque le travail s'accumule.

4) Protection réseau : circuit-breaker et élimination des « mauvais »

Envoy/Istio outlier detection (идея)

yaml outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

Circuit breaker limite les requêtes/connexions simultanées afin de ne pas réduire la dépendance.

Rate limiting

Limitez les appels d'entrée/itinéraires PSP/fournisseurs de jeux afin que la vague de retraits n'amplifie pas l'accident.

5) Retraits, timeouts et backoff avec jitter

Règle : d'abord le timout, puis la rétrospective, toujours avec le gitter et la limitation des tentatives.

python def backoff(attempt, base=0. 1, cap=2. 0):
import random, math sleep = min(cap, base (2 attempt))
jitter = random. uniform(0, sleep 0. 4)
return sleep + jitter

Pour les paiements - clés idempotent + déduplication.
Pour les files d'attente, dead-letter et les tentatives répétées retardées.

6) Auto-récupération dans les files d'attente/streaming

DLQ + alertes de croissance ; Recasage isolé.
Contrôle lag : auto-skale consumers (KEDA), backpressure aux producteurs.
Exactly-once/at-least-once - choisi consciemment ; les opérations sont idempotentes.

7) Cache et warm-up

Clés de versage ('v2 :') pour une incapacité/un retour en toute sécurité.
Pools chauds de composés vers l'OBD/PSP ; échauffement avant les changements (bleu-vert/canary).
Stale-while-revalidate pour réduire les coups « froids » sur les OBD.

8) Auto-remediation par SLO (actions sur les signaux)

• Stop canary / rollback при fast-burn.
• Scale-out workers à la croissance 'queue _ lag _ second'.
• Activer le mode degrade (UX simplifié, désactivation des fiches lourdes).
• Basculement de l'itinéraire PSP à timeouts spike.
• Activation de feature-flag kill-switch.

yaml alert: WithdrawalsQueueLag labels: { action: "scale_workers", target: "withdrawals-consumers", by: "+5" }

9) Mode de dégradation (graceful degradation)

Simplifier l'interface utilisateur (moins de requêtes), désactiver les widgets « chers ».
Plus de cache, moins de fan-outs/aggrégations.
Pour les LLM/recommandations, réduire la taille du contexte/modèle, inclure « fast path ».

10) Approche GitOps pour les auto-émissions

Toutes les stratégies de remediation automatique et les paramètres (délais, seuils) sont dans Git.
Toute action automatique crée une annotation dans Grafana et une entrée dans le journal des modifications.
Les politiques canaries et les gates SLO sont aussi un code.

11) Ingénierie du chaos : Nous vérifions que la guérison fonctionne

Injections de défaillances : retards du réseau, chute des pods, défaillance de l'émulateur PSP, larme de file d'attente.
Scripts game-day : nous mesurons MTTR, la qualité des actions auto, la présence d'artefacts.
Résultats → mise à jour des runabooks, seuils, ficheflags.

12) Observabilité pour auto-healing

Exemplars : saut rapide de la métrique p95 à la piste.
Logs avec 'trace _ id'et les champs' retry ',' attempt ',' degrade _ mode = true '.
Dashboards release compare (stable vs canary), carte SLO.
Audit auto-action : qui/quoi/quand, métriques initiales, résultat.

13) Sécurité et conformité

Pas de secrets dans les logs/métriques des auto-remediations.
Pour les actions de paiement - double confirmation/rôle.
Geo/PII - Ne détournez pas le trafic vers la « mauvaise » région lors d'un faux vol.

14) Modèles pratiques

Istio DestinationRule — connection pool & outlier

yaml trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1000, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

Flagger - canary avec moteur/retour

yaml analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

KEDA ScaledObject — Kafka lag

yaml triggers:
- type: kafka metadata:
topic: withdrawals bootstrapServers: broker:9092 consumerGroup: w-consumers lagThreshold: "5000"

15) Chèque de mise en œuvre

1. Startup/read..../liveness et endpoints santé sont personnalisés.
2. Limites/requêtes de ressources + PDB/anti-affinité.
3. HPA/KEDA pour les API et les workers ; métriques lag/throughput.
4. Circuit-breaker, outlier-ejection, rate-limit en gate/mesh.
5. Retrai avec backoff + jitter, idempotence des opérations de paiement.
6. Caches de version et degrade-mode.
7. SLO-gates → auto-action (rollback/scale/reroute/kill-switch).
8. GitOps code des stratégies + audit des actions, annotations des versions.
9. Tests de chaos et game-day sur les scénarios clés.
10. Dashboards MTTR/Alert Quality et rapports sur les auto-remediations.

16) Anti-modèles

Liveness « cloue » le processus en raison de la dépendance temporelle → flapping.
Retrai sans temporisateur/jitter → tempête de demandes.
HPA par CPU dans les services dépendants de l'IO → « nulle part ».
Cache partagé sans version pour les restaurations → la corruption de données.
Actions automatiques sans audit/URL Runbook.
Pas de DLQ/métriques lag → accumulation silencieuse de la dette.
Mélange auto-healing et « masquer les problèmes » : l'automatisation traite les symptômes, la racine n'est pas corrigée → la répétition des incidents.

Résultats

L'auto-guérison est une discipline d'ingénierie : échantillons et limites de qualité, retraits et isolation, actions automatiques sur les signaux SLO, plus vérifications et audits de chaos. Ce circuit rend la plate-forme résistante aux pannes, réduit MTTR et prend en charge les mesures clés d'iGaming - p99, conversion de paiement et TTW - même aux heures les plus chaudes.