Chaos Engineering : Durabilité des systèmes

Chaos Engineering : Durabilité des systèmes

1) Pourquoi le chaos-ingénierie

• tester les hypothèses sur le comportement du système et valider le SLO ;
• Détecter des SPOF cachés, des temporisations/retraits incorrects, des effets en cascade ;
• Entraîner les équipes : jeux-jours, runbook, communications ;
• former une culture de « durabilité par défaut » plutôt que de « espérer le meilleur ».

Important : Chaos Engineering ≠ « tout casser ». C'est une méthode scientifique : steady-state → hypothèse → expérience → conclusions → améliorations.

2) Cycle de base de l'expérience

1. Steady-state (ligne de base) : quels SLI sont stables ? (par exemple, succès ≤500 ms à 99. 95%).
2. Hypothèse : Avec la perte d'un AZ p95, la croissance est <10 % et la disponibilité est ≥99. 9%.
3. Expérience : Folt planifié avec radius blast limité et critères stop.
4. Observation : métriques/trajets/logs, SLO à taux variable, SLI d'entreprise (par exemple, dépôts réussis).
5. Améliorations : nous enregistrons les découvertes, nous changeons les délais/limites/routage, nous mettons à jour le runbook.
6. Automatisation/régression : nous le répétons dans l'horaire, l'ajoutons dans le CI/CD et les calendriers des jours de jeu.

3) Balise de sécurité (première sécurité)

Blast radius : nous commençons par étroit - un pod/instance/route/namespace.
Guardrails : alertes sur SLO burn-rate (rapide/lent), limites de retraits, limite QPS, budget incident.
Critères stop : « Si error-rate> X % ou p99> Y ms N minutes est instantanément stop et rollback ».
Fenêtres : heures de travail sur appel, stackholders notifiés, versions congelées.
Communication : IC/Tech lead/Comms, canal clair (salle de guerre), modèle de message.

4) Classes de refus et idées d'hypothèses

Réseau : retard/jitter/perte, drop partiel des ports, communication « flash » entre les services/PSP.
Compirit/nœuds : tuer les processus, surchauffer le CPU, épuiser les descripteurs de fichiers, pools étroits de connexions.
Stockage et OBD : croissance des disques latins, lag répliques, stop one shard/leader, split-brain.
Dépendances : dégradation des API externes, limites des fournisseurs, surtensions 5xx/429.
Gestion du changement : mauvaise sortie, mauvais drapeau ficha, rollout partial.
Périmètre : CDN dégradé, dérive DNS/Anycast, faille de protection WAF/bot.
Région/AZ : perte totale ou incident « partiel » (un peu pire et imprévisible).

5) Outils et techniques

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Nuages : AWS Fault Injection Simulator (FIS), Fault Domaines près des nuages.
Réseau/proxy : Toxiproxy (TCP-poison), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Processus/nœuds : 'stress-ng', cgroups/CPU-throttle, disk fill.
Trafic-routage : GSLB/DNS weights, commutation canary/blue-green pour les contrôles de faussaire.

6) Exemples de scénarios (Kubernetes)

6. 1 Delay/abort sur la route (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Hypothèse : les délais/retraits clients et les CB tiendront p95 <300 ms et error-rate <0. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Hypothèse : l'équilibreur et l'HPA compensent le loss d'une instance sans croissance p99> 20 %.

6. 3 Chaos du réseau (retard à la base de données)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Hypothèse : les pools/délais/cache réduiront l'impact ; p95 paiements resteront ≤ SLO.

6. 4 Remplissage du disque

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

Hypothèse : la rotation des logs/quotas/alerts fonctionnera avant la dégradation des itinéraires.

7) Expériences hors du K8s

7. 1 Toxiproxy (local/intégratif)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTP fault (périmètre/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (exemple d'idée)

L'expérience « tuer » N % EC2 dans Auto Scaling Group, soulever artificiellement EBS-latency, désactiver NAT-GW dans un AZ.
Critères d'arrêt intégrés selon les métriques SLO CloudWatch.

8) Métriques d'observabilité pendant le chaos

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
Modèle RED sur les itinéraires critiques (Rate, Errors, Durée).
Pools : attente du composé p95, utilisation.
BD : lag réplique, locks, dérive p95 requêtes.
Réseau : retransmits, RTT, dscp/ecn comportement.
SLI d'entreprise : succès des transactions (dépôts/chèques), % des retours/erreurs.
Trace : Traces sélectives (exemplars), corrélation de sortie-annotation.

9) Intégration avec SLO/Error-budget

Planifiez des expériences dans le cadre du budget des erreurs : le chaos ne devrait pas « perturber » les objectifs trimestriels.
Burn-rate alerts comme automatique kill-switch.
Reporting : « combien de budget brûlé », « quelles déviations steady-state ».

10) Journées de jeu (exercices)

Scénario : brève légende (par exemple, « Région-Est perdu »), étapes d'injection, objectifs de SLO, rôles, temps.
Évaluation : RTO/RPO réel, qualité des communications, exactitude du runbook.
Rétro : liste des améliorations avec les propriétaires et les échéances, mise à jour de la documentation/dashboards.

11) Automatisation et CI/CD

Smoke-chaos : courts tests de staging à chaque sortie (par exemple 1 pod-kill + 200 ms delay par itinéraire).
Nocturnes/hebdomadaires : scénarios plus sévères (5-15 min) avec rapport.
Gates promo : Si p95/erreurs> seuil sur canary - auto-retour.
Référentiels avec catalogue d'expériences (YAML + runbook + SLO-thresholds).

12) Anti-modèles

« Casser la prod sans balustrade » : il n'y a pas de critères stop, il n'y a pas d'appel → le risque d'un véritable incident.
Promotion unique au lieu du processus.
Chaos sans state steady : on ne sait pas quoi considérer comme succès/échec.
Retraits excessifs → sama-DDoS lors de l'injection de retards.
Ignorer le SLI d'entreprise : succès « Technar » dans l'échec des paiements/commandes.
L'absence de post-analyse et de propriétaires d'améliorations.

13) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Définir le SLI steady-state (utilisateur + entreprise).
Sélectionner un outil (Chaos Mesh/Litmus/Toxiproxy/FIS).
Décrire la rampe : radius blast, critères stop, fenêtres, rôles.

11-25 jours

Lancez les premières expériences : pod-kill, 100-200 ms delay par apstream critique, drop 1 % des paquets.
Configurer les alertes burn-rate, lier kill-switch aux critères stop.
Passer la première journée de jeu, ramasser rétro et fictions.

26-45 jours

Ajouter des scripts de niveau AZ/dépendances (PSP externe, BD-lag).
Automatiser le chaos nocturne sur le staging ; préparer des scénarios « saisonniers » (pics).
Catalogue d'expériences et rapports réguliers pour la direction/SRE.

14) Métriques de maturité

≥80 % des itinéraires critiques ont des expériences décrites et des métriques steady-state.
Auto kill-switch se déclenche lorsque les seuils p99/error-rate sont dépassés.
Chaque trimestre est un jeu-jour de niveau AZ/région, et ≥1 fois/mes est un scénario de dépendance cible.
MTTR diminue après un cycle d'amélioration, la corrélation « sortie ↔ incident » diminue.
La part des chutes « inattendues » dans les pannes réelles tend → vers zéro.
Dashboard montre la « résilience » en tant que KPI (burn-rate, temps de récupération, proportion d'actions DR réussies).

15) Exemples de guardrails et déclencheurs stop

Stop à : 'http _ req _ failed> 1 %' 3 minutes, 'p99> 1000 ms' 3 fenêtres,' deposit _ success <99. 5%`.
Réduction du radius blast : Auto-retour du manifeste, retour des échelles GSLB, arrêt des injections fault.
Commande stop : bouton unique/script avec logigation des causes.

16) Culture et processus

Le chaos fait partie du rythme SRE, pas « extrême ».
Rapports transparents, reconnaissance des vulnérabilités, mesures correctives.
Formation en ligne, simulation de communication avec les clients/partenaires.
Lien avec les SLA/SLO et les budgets : le chaos doit augmenter, et non compromettre, la fiabilité.

17) Conclusion

Chaos Engineering transforme « l'espoir des neuf » en une durabilité prouvée. Formulez un état steady, mettez des rampes, cassez les petites et contrôlables, observez les SLO et les SLI d'entreprise, enregistrez et automatisez les améliorations. Les défaillances réelles deviendront alors des événements gérables : un RTO prévisible, un budget error protégé et une équipe prête à agir sans panique.