49 lines
1.5 KiB
Markdown
49 lines
1.5 KiB
Markdown
---
|
|
title: Chaos Engineering
|
|
created: 2026-06-06
|
|
updated: 2026-06-06
|
|
type: concept
|
|
tags: [devops, tech, resilience]
|
|
confidence: high
|
|
contested: false
|
|
sources: [synthesized]
|
|
---
|
|
# 💥 Chaos Engineering
|
|
|
|
## Définition Courte
|
|
Discipline consistant à **injecter volontairement des pannes** dans un système pour observer sa résilience et identifier les faiblesses avant qu'elles ne surviennent en production.
|
|
|
|
## Explication Détaillée
|
|
Popularisé par Netflix (via les Chaos Monkey), le Chaos Engineering suit ces étapes :
|
|
1. Définir un "steady state" (état normal mesurable).
|
|
2. Émettre une hypothèse (ex: "si la DB tombe, le service reste dégradé").
|
|
3. Injecter un défaut (kill d'instance, latence, erreur réseau).
|
|
4. Observer l'écart au steady state.
|
|
5. Apprendre et améliorer.
|
|
|
|
**Avantages** : résilience mesurée, culture de la fiabilité, découverte de bugs cachés.
|
|
**Inconvénients** : demande de la maturité, peut être coûteux à mettre en place.
|
|
|
|
## Cas d'Usage
|
|
- Microservices à fort trafic.
|
|
- Validation de stratégies de fallback.
|
|
- Tests de disaster recovery.
|
|
|
|
## Outils Liés
|
|
- **Chaos Monkey** (Netflix).
|
|
- **Gremlin** (commercial, complet).
|
|
- **Litmus** (Kubernetes-native).
|
|
- **ChaosBlade** (Alibaba).
|
|
|
|
## Pages Liées
|
|
- [[observabilite]]
|
|
- [[architecture-microservices]]
|
|
- [[ci-cd]]
|
|
|
|
## Questions Ouvertes
|
|
- Le chaos engineering est-il rentable pour une PME ?
|
|
- Comment convaincre la direction de "casser la prod volontairement" ?
|
|
|
|
## Liens
|
|
- [[load-shedding]]
|