Chaos Engineering to praktyka, w której celowo psujesz własny system w kontrolowanych warunkach, żeby sprawdzić, czy naprawdę jest tak odporny, jak myślisz. Zamiast czekać, aż produkcja padnie o 3 w nocy podczas Black Friday, sam wywołujesz awarię w ciągu dnia, z kawą w ręku i zespołem pod telefonem. Chodzi o to, by odkryć słabe punkty zanim zrobią to za Ciebie użytkownicy.
Pomysł spopularyzował Netflix narzędziem Chaos Monkey, które losowo wyłączało instancje serwerów w środowisku produkcyjnym. Skoro maszyny i tak czasem padają same, lepiej oswoić ten scenariusz na własnych zasadach. Z tego wyrosły oficjalne Principles of Chaos Engineering: definiujesz „stan ustalony” (steady state), czyli jak wygląda zdrowy system w metrykach (np. liczba zamówień na minutę), stawiasz hipotezę („padnie jeden węzeł, a użytkownik nic nie zauważy”), wstrzykujesz awarię i sprawdzasz, czy hipoteza się broni.
Jak to wygląda w praktyce
Typowy eksperyment to nie „wyciągnijmy kabel i zobaczmy”. Zaczynasz mały, najlepiej na środowisku testowym, z jasno określonym blast radius (zasięgiem skutków) i przyciskiem awaryjnego stopu. Wstrzykujesz konkretną awarię: opóźnienie sieci, padnięcie kontenera, wyczerpanie CPU, niedostępność zależnej usługi.
Popularne narzędzia to Gremlin (komercyjne), Chaos Toolkit, LitmusChaos oraz AWS Fault Injection Service. W świecie Kubernetes często używa się Chaos Mesh. Prosty przykład z Chaos Mesh: aby na 30 sekund „zabić” losowy pod, opisujesz eksperyment w YAML i aplikujesz go przez kubectl apply -f pod-failure.yaml. Obserwujesz dashboardy: czy ruch przełączył się na zdrowe instancje, czy retry zadziałały, czy alerty w ogóle się odpaliły.
Częste błędy i mity
- „To losowe psucie produkcji” — nie. To zaplanowany eksperyment z hipotezą, monitoringiem i planem odwrotu. Losowy chaos bez metryk to po prostu awaria.
- Brak baseline’u. Jeśli nie wiesz, jak wygląda zdrowy system, nie poznasz, że eksperyment coś zepsuł.
- Start od produkcji. Najpierw staging, mały blast radius, dopiero potem ostrożnie produkcja.
- Brak guardrails. Zawsze miej automatyczne przerwanie eksperymentu, gdy metryki przekroczą próg.
Warto pamiętać, że Chaos Engineering ma sens dopiero, gdy masz przyzwoity observability (metryki, logi, tracing). Bez tego psujesz w ciemno.
Pojęcia powiązane: resilience (odporność), fault injection, SRE (Site Reliability Engineering), observability, blast radius, steady state, high availability, disaster recovery oraz Chaos Monkey jako protoplasta całego podejścia.