Inżynieria chaosu

1) Podstawowe zasady

Stan stacjonarny jako pierwotna hipoteza. Jasno zdefiniować normę (na przykład: p95 <200 ms, wskaźnik błędu <0. 3%, sukces krytyczny> 99. 5%).
Pojedyncze zmienne. Zmień jak najwięcej jeden czynnik na raz, aby przyczynowo powiązać efekt i poprawę.
Stopień. Zaczynamy od małych amplitudy w bezpiecznym środowisku → rozszerzyć zasięg i intensywność.
Poręcze ochronne. Wyraźne warunki zatrzymania w budżecie SLO/alert/error.
Powtarzalność. Eksperyment musi być odtwarzalny odtwarzalnie (skrypty/manifesty/IaC).
Etyka i bezpieczeństwo. Brak prawdziwych danych osobowych i transakcji finansowych w ryzykownych eksperymentach.

2) Czym jest „stabilny stan”

• p50/p95/p99 opóźnienia kluczowych punktów końcowych.
• Wskaźnik sukcesu i konwersja ścieżki krytycznej.
• Wskaźnik błędów, terminy, odsetek żądań „shed” (skrócony na nasyceniu).
• Szybkość samouzdrawiania (MTTR), oporność na odwrót (bez burz).
• Niezmienne domeny: brak „minusów w saldzie”, po dokonaniu płatności, spójność dni raportowania itp.

3) Katalog wtrysku (co łamiemy)

Sieć: opóźnienie, jitter, utrata/duplikaty, ograniczenie przepustowości, przerwy TLS, klapowanie DNS.
Obliczenia: przeciążenie procesora, ciśnienie pamięci/GC, wyczerpanie deskryptora, skew zegara.
Przechowywanie: wysoka p95 I/O, ENOSPC, awaria lidera/repliki, podział mózgu, fsync.
Zależności: 5xx/429, „powolny sukces”, degradacja zewnętrznych API, limit szybkości.
Dane: duplikaty/brakujące wiadomości, nieporządek, brudne rekordy, konflikt wersji.
Operacje: nieudane zwolnienie/konfiguracja, flaga funkcji z błędem, wygasły certyfikat, obrót klucza.
Ludzie i procesy: niedostępność odpowiedzialnych, opóźnienie ręcznej aktualizacji, nieprawidłowy runbook.

4) Projekt eksperymentu (szablon)

1. Hipoteza: „Przy + 300 ms do usługi walutowej p99 głównego API <450 ms, wyłącznik otwiera się, odpowiedź ciągła jest podana ≤ 15 minut temu”.
2. Wstrzyknięcie: profil awarii (typ/amplituda/czas trwania) i kontur docelowy.
3. Metrics/log tags: marking 'chaos. experiment_id', 'faza = wstrzyknięcie' recover '.
4. Poręcze: przerwać z 'error _ rate> 2%' lub p99> SLA × 2 przez więcej niż 1 minutę.
5. Wyniki/wyjście: lista obserwacji, błędów, ulepszeń, planu pracy i ponownego uruchomienia.

5) Obserwowalność: co jest obowiązkowe

Śledzenie: ścieżka żądania przez zależności; segmenty z degradacją są oznaczone.
Mierniki zasobów: CPU, hałas/GC, FD, dysk IOPS/lat, przepustowość sieci, głębokość kolejki.
Wskaźniki biznesowe: konwersja/sukces operacji, udział kompensowanych transakcji.
Dzienniki zdarzeń: otwarcie/zamknięcie wyłączników, przekaźniki i ich budżet, przełączanie lidera bazy danych.
Panel eksperymentalny: tablica rozdzielcza z progami barier i „czerwonym przyciskiem” aborcji.

6) Szyny ochronne i bezpieczeństwo

Techniczne: górne granice wskaźnika błędu/opóźnienia, spadek udziału udanych operacji, wzrost DLQ.
Organizacja: okno czasu, dyżur zaangażowany, zasada „jedna strefa - jeden eksperyment”.
Dane/zgodność: tylko syntetyczne lub bezosobowe zestawy; zakazanie testów prowadzących do naruszeń przepisów.
Rollback: gotowy zwrot/wyłączyć procedurę flagi/miękkiego spustu.

7) Wzory odporności, które powinny pojawić się

Budżety Timeout i rekolekcje jitter (bez burzy).
Wyłącznik z półotwartym i wykładniczym odzyskiem.
Grodzie: izolacja puli krytycznych (płatności vs analityk).
Ciśnienie wsteczne i ograniczenie prędkości: przewidywalny niski priorytet cutoff.
Cache z koalescingiem, ochrona przed „burzami rozgrzewającymi”.
Idempotencja działań niepożądanych i sagi z działaniami wyrównawczymi.
Kworum, feilover i anty-entropia do odzyskiwania danych.

8) Przykładowe scenariusze (szkice)

8. 1 powolna zależność (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 Utrata lidera DB

Wtrysk: Zatrzymanie lidera/wymuszona reelekcja.
Oczekiwanie: tymczasowe hamowanie pisania, czytanie kworum, sejf WAL/Outbox, automatyczne przywracanie replikacji, brak podwójnego zapisu.

8. 3 ENOSPC na dysku dziennika

Wstrzyknięcie: wypełnić dysk do 95-100%.
Czekanie: awaryjny obrót kłód, bezpieczeństwo dzienników krytycznych, wyłączanie funkcji innych niż krytyczne, alarm i automatyczna naprawa.

8. 4 Ruch rozruchowy + zacienienie

Wstrzyknięcie: × 3 RPS przez 5 minut na gorącym punkcie końcowym.
Oczekiwanie: zrzucenie niskiego priorytetu, stabilny p95 „rdzeń”, brak kaskady retray.

9) Automatyzacja w CI/CD

Chaos-dym na etapie każdego uwalniania (krótkie zastrzyki przy bezpiecznych amplitudach).
Nocne działa zgodnie z katalogiem eksperymentów (usługi matrycowe × rodzaje awarii).
Bramy: Zwolnienie jest zablokowane, jeśli „trwałość jest poniżej progu” (na przykład odsetek udanych awarii wynosi <95%).
Artefakty: raport, szlaki, CPU/hałas, migawki metryk i konfiguracji.

10) Dni gry (Dni gry)

• Role: lider eksperymentu, obserwator metryki, operator rollback, przedstawiciel biznesu.
• Scenariusze: degradacja pamięci podręcznej, częściowa awaria AZ/region-feilover, „złe uwolnienie”, niedostępność zewnętrznego dostawcy.
• Wyniki: znaleziono luki w książce startowej, ulepszenia w zakresie wpisów, dostosowania SLO i przekwalifikowania budżetów.

11) Chaos w odniesieniu do danych, zdarzeń i ML

Strumienie danych: testy na duplikaty, luki, nieporządki, opóźnienia; walidacja idempotentnych konsumentów i strategii DLQ.
Repozytoria: degradacja indeksu, partycja gorąca, konflikt blokady, replikacja pod opóźnieniem.
ML: opóźnienie funkcji, powrót do modelu wyjściowego, degradacja jakości danych wejściowych (dryf) - system powinien „miękko tępy” i nie padać.

12) Anty-wzory

Chaos bez obserwacji: jesteś „ślepy”, wnioski są spekulacyjne.
Wstrzyknięcia natychmiast w prod bez szyn stacjonarnych i ochronnych.
„Jeden wielki eksperyment” na wszystko naraz - nie wiadomo, co dokładnie zadziałało.
Chaos haphazard działa bez hipotez i powtórzeń po naprawach.
Skupienie się tylko na infrastrukturze - niezmienne przedsiębiorstwa są zapomniane.
Ignorowanie ludzi/procesów: alerty, dyżury, runbook - część systemu.

13) Dojrzałość praktyki (model)

1. Doraźne: pojedyncze wstrzyknięcia lokalnie.
2. Chaos sceniczny: katalog scenariuszy, powtarzające się biegi, deski rozdzielcze.
3. Uwolnić chaos: chaos dymu w każdym wydaniu, bramy, raporty.
4. Chaos żywności z ograniczeniami: niski ruch, ścisłe szyny ochronne, gotowy zwrot.
5. Stabilność ciągła: automatyczne eksperymenty, zarządzanie SLO, ulepszenia jako przepływ pracy.

14) Integracja z praktykami architektonicznymi

Badanie odporności: Eksperymenty chaosu uzupełniają wtryskiwanie usterek i scenariusze degradacji.
Badanie obciążenia: Połączone obciążenia + eksperymenty awaryjne ujawniają kaskady i burzę retras.
Polityka jako kod/RBAC/ABAC: poręcze, kroki wsteczne i limity są projektowane jako polityki.
Zarządzanie zgodą/prywatnością: nie zezwalaj na eksperymenty naruszające tryb przetwarzania danych.
Geo-architektura: chaos-kontrole awarii regionów i dane wiążące jurysdykcje.

15) Mini przepisy (pseudokoda)

Wyłącznik + degradacja

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()

Limiter + zacienienie

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

Idempotentne działanie niepożądane

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

16) Lista kontrolna architekta

1. Zdefiniowane stacjonarne i barierki?
2. Czy istnieje katalog skryptów (network/CPU/storage/dependencies/data/operations)?
3. Czy obserwowalność obejmuje zasoby, ogony opóźnienia, niezmienne w biznesie?
4. Timeouts/retreats/breakers/limiters/grodzi enabled and parameterizable?
5. Przygotowana książka startowa i „czerwony przycisk”?
6. Czy na scenie i nocnych eksperymentach panuje chaos-dym?
7. Czy są „bezpieczne” okna i role na dni gry?
8. Eksperymenty są powtarzalne (IaC/skrypty), wyniki są weryfikowane?
9. Ulepszenia są ustalane przez zadania, powtórzenie jest wykonywane?
10. Dane i rurociągi ML objęte, nie tylko HTTP?

Wniosek

Chaos Engineering zmienia „nieprzewidziane incydenty” w przewidywalne scenariusze. Hipoteza oporności, kontrolowane wstrzyknięcia, sztywne szyny ochronne, bogata obserwowalność i retest dyscypliny są narzędziami, które zmniejszają ryzyko uwolnień i zwiększają zaufanie do platformy. W rezultacie zespół rozumie granice systemu, jest w stanie elegancko degradować i szybko zwracać usługę użytkownikowi, nawet w warunkach awarii.