Chaos Engineering

1) Principes de base

Steady State comme hypothèse initiale. Définissez clairement la norme (par exemple : p95 <200 ms, error rate <0. 3 %, succès du flow critique> 99. 5%).
Variables isolées. Si possible, changez un facteur à la fois pour lier l'effet et l'amélioration.
Degré. Nous commençons par de petites amplitudes dans un environnement sûr → étendons la couverture et l'intensité.
Guardrails. Conditions d'arrêt explicites pour SLO/alerts/budget d'erreur.
Répétabilité. L'expérience doit être déterministe (scripts/manifestes/IaC).
Éthique et sécurité. Pas de données personnelles réelles et de transactions financières dans des expériences risquées.

2) Qu'est-ce qu'un « état durable »

• Latence p50/p95/p99 endpoints clés.
• Proportion de transactions réussies et conversion de chemins critiques.
• Taux d'erreur, délais, proportion de requêtes « shed » (coupées à saturation).
• Vitesse d'auto-guérison (MTTR), résistance aux rétractions (pas de tempêtes).
• Invariants du domaine : l'absence de « contre dans le bilan », les paiements une fois exécutés, la cohérence des jours de rapport, etc.

3) Catalogue des injections (que « casser »)

Réseau : latence, jitter, perte/duplication, limitation de bande passante, falaises TLS, flapping DNS.
Calculs : surcharge de CPU, pression de la mémoire/GC, épuisement des descripteurs, clock skew.
Stockage : haute p95 I/O, ENOSPC, échec leader/réplique, split-brain, fsync prolongé.
Dépendances : 5xx/429, « succès lent », dégradation des API externes, rate-limit.
Données : prises/omissions de messages, out-of-order, entrées « sales », conflit de versions.
Opérations : Sortie/config ratée, drapeau ficha avec bug, certificat expiré, rotation de clé.
Personnes et processus : inaccessibilité des responsables, retard de l'aprouve manuelle, mauvais runbook.

4) Conception de l'expérience (modèle)

1. L'hypothèse : "À +300 мс vers le service de change p99 de l'essentiel API <450 мс, s'ouvre брейкер, se donne la stale-réponse ≤ 15 prescriptions momentanées".
2. Injection : profil de défaillance (type/amplitude/durée) et boucle cible.
3. Métriques/labels : marquage 'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails : abort à 'error _ rate> 2 %' ou p99> SLA × 2 pendant plus de 1 minute.
5. Résultats/conclusions : liste des observations, bogues, améliorations, plan de travail et reprise.

5) Observabilité : ce qui est obligatoire

Tracing : chemin de requête à travers les dépendances ; les segments dégradés sont marqués.
Métriques de ressources : CPU, heap/GC, FD, disques IOPS/lat, bandwidth réseau, profondeur de file d'attente.
Mesures commerciales : conversion/succès des opérations, proportion de transactions compensées.
Logs d'événements : ouverture/fermeture des breakers, retrai et leur budget, changement de leader de la BD.
Panneau d'expérience : live-dashboard avec seuils de garde et « bouton rouge » de l'avortement.

6) Les gardes et la sécurité

Technique : limite supérieure error rate/latency, baisse de la proportion d'opérations réussies, croissance de DLQ.
Organisation : fenêtre temporelle impliquée, principe « une zone - une expérience ».
Données/conformité : seuls les kits synthétiques ou impersonnels ; l'interdiction des tests conduisant à une violation de la réglementation.
Retour en arrière : routine rollback/disable drapeau/drain doux trafic.

7) Les modèles de durabilité qui doivent se manifester

Budgets Timout et retraits jitter (pas de tempêtes).
Circuit Breaker avec semi-étincelle (half-open) et récupération exponentielle.
Bulkheads : Isolation des pools par criticité (paiements vs analytics).
Backpressure et rate-limit : coupure prévisible de faible priorité.
Cache avec coalescing, protection contre les « tempêtes de réchauffage ».
L'idempotence des effets secondaires et de la saga avec des actions compensatoires.
Quorum, faussaire et anti-entropie pour récupérer les données.

8) Exemples de scénarios (sketches)

8. 1 Dépendance lente (YAML)

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8. 2 Perte du leader de la DB

Injection : arrêt du leader/réélection forcée.
Attente : interdiction temporaire des entrées, lecture à partir du quorum, sécurité WAL/Outbox, auto-récupération de réplication, pas de double écriture.

8. 3 ENOSPC sur le disque journal

Injection : remplissage du disque jusqu'à 95-100 %.
Attente : rotation d'urgence des logs, conservation des journaux critiques, désactivation des fiches non critiques, alert et auto-remediation.

8. 4 Burst-trafic + shading

Injection : × 3 RPS pendant 5 minutes par endpoint chaud.
Attente : rejet de faible priorité, p95 « noyau » stable, pas de cascade de retraits.

9) Automatisation en CI/CD

Chaos-smoke dans le steadge pour chaque sortie (injections courtes sur des amplitudes sûres).
Les courses nocturnes sur le catalogue d'expériences (matrice des services × types de défaillances).
Gates : la sortie est bloquée si la « résilience est inférieure au seuil » (par exemple, la proportion de fallback réussie <95 %).
Artefacts : rapport, tracés, flûtes CPU/heap, snapshots de métriques et de configues.

10) Jours de jeu (Game Days)

• Rôles : chef d'expérience, observateur de métriques, opérateur de retour, représentant de l'entreprise.
• Scénarios : dégradation du cache, défaillance partielle d'AZ/région faussaire, « mauvaise sortie », indisponibilité du fournisseur externe.
• Résultats : lacunes constatées dans le runbook, améliorations des alertes, ajustements du SLO et des budgets rétrogrades.

11) Chaos pour les données, les événements et ML

Flux de données : tests de duplication, omissions, out-of-order, retards ; vérification des consumers idempotent et des stratégies DLQ.
Stockage : dégradation des index, hot-partition, conflit de verrouillage, réplication sous la lagune.
ML : retard de phase store, retour au modèle baseline, dégradation de la qualité des données d'entrée (drift) - le système doit être « doucement stupide », pas tomber.

12) Anti-modèles

Chaos sans observabilité : vous êtes « aveugle », les conclusions sont spéculatives.
Injections à la fois dans la vente sans steak et les vols de garde.
« Une grande expérience » sur tout à la fois - on ne sait pas exactement ce qui a marché.
Des actions de chaos sans hypothèse et reteste après les fictions.
Se concentrer uniquement sur l'infrastructure - les invariants d'affaires sont oubliés.
Ignorer les personnes/processus : alertes, on-call, runbook font partie du système.

13) Maturité de la pratique (modèle)

1. Ad hoc : injections ponctuelles localement.
2. Stadge chaos : catalogue de scripts, essais répétés, dashboards.
3. Release-chaos : smoke-chaos dans chaque release, gates, rapports.
4. Prod chaos avec restrictions : petit trafic, rigoureux guardrails, prêt à reculer.
5. Durabilité continue : Auto-expérimentation, SLO-control, amélioration comme flux de travail.

14) Intégration avec les pratiques architecturales

Tests de résistance : les expériences de chaos complètent les cas d'injection et de dégradation.
Tests de charge : les expériences combinées « charge + panne » révèlent les cascades et les tempêtes de rétraction.
Policy as Code/RBAC/ABAC : guardrails, étapes de retrait et limites à remplir en tant que politiques.
Gestion du consentement/vie privée : Ne tolérez pas les expériences qui perturbent le mode de traitement des données.
Géo-architecture : Vérification du faussaire des régions et liaison des données aux juridictions.

15) Mini recettes (pseudo-code)

Breaker + dégradation

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

Limite + shading

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Effet indésirable idempotent

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16) Chèque de l'architecte

1. Identifié par Steady State et guardrails ?
2. Avez-vous un répertoire de scripts (réseau/CPU/stockage/dépendances/données/opérations) ?
3. L'observabilité couvre les ressources, les résidus de latence, les invariants d'affaires ?
4. Temps/Retrai/Breakers/Limiters/Bulkheads inclus et paramétrages ?
5. Un runbook et un « bouton rouge » ?
6. Y a-t-il du chaos-smoke dans le stadge et des expériences nightly ?
7. Des fenêtres « sûres » et des rôles sur les jours de jeu ?
8. Les expériences sont reproductibles (IaC/scripts), les résultats sont-ils versionnés ?
9. Les améliorations sont enregistrées par des tâches, un retest est fait ?
10. Les convoyeurs de données et ML sont couverts, pas seulement HTTP ?

Conclusion

Chaos Engineering transforme les « incidents imprévus » en scénarios prévisibles. L'hypothèse de la résilience, les injections contrôlées, les guardrails rigides, la riche observabilité et la discipline des retestes sont des outils qui réduisent le risque de libération et renforcent la confiance dans la plateforme. En fin de compte, l'équipe comprend les limites du système, sait se dégrader élégamment et rendre rapidement le service à l'utilisateur, même dans des conditions de défaillance.