Inżynieria chaosu: Odporność systemu

Inżynieria chaosu: Odporność systemu

1) Dlaczego inżynieria chaosu

• hipotezy testowe dotyczące zachowania systemu i walidacji SLO;
• wykrywanie ukrytych SPOFs, nieprawidłowe timeouts/retrays, efekty kaskadowe;
• zespoły pociągów: gra-dni, ćwiczenia, komunikacja;
• tworzyć „zrównoważoną kulturę domyślnie” zamiast „liczyć na to, co najlepsze”.

Ważne: Inżynieria chaosu "przełamać wszystko. "Jest to metoda naukowa: stan stacjonarny → hipoteza → eksperyment → wnioski → poprawa.

2) Podstawowy cykl eksperymentalny

1. Stan stacjonarny (wartość wyjściowa): Które SLIs są stabilne? (na przykład sukces ≤ 500 ms przy 99. 95%).
2. Hipoteza: z utratą jednej AZ, p95 wzrośnie <10%, a dostępność ≥ 99. 9%.
3. Eksperyment: planowany faul o ograniczonym promieniu wybuchu i kryteriach zatrzymania.
4. Obserwacja: mierniki/ścieżki/dzienniki, szybkość spalania SLO, biznes SLI (na przykład, udane depozyty).
5. Ulepszenia: rejestrujemy znaleziska, zmieniamy timeouts/limits/routing, aktualizujemy runbook.
6. Automatyzacja/regresja: powtórzyć w harmonogramie, dodać do CI/CD i kalendarzy dni gry.

3) Bezpieczeństwo najpierw

Promień wybuchu: rozpocząć od wąskiej - jednej części/instancji/trasy/przestrzeni nazw.
Poręcze: alerty do prędkości spalania SLO (szybki/powolny), limity przekaźników, limit QPS, budżet incydentów.
Kryteria Stop: „jeśli błąd-szybkość> X% lub p99> Y ms N minut - natychmiast zatrzymać i rollback”.
System Windows: dyżurne godziny pracy, zgłoszone zainteresowane strony, zamrożone wydania.
Komunikacja: IC/Tech lead/Comms, clear channel (War-room), szablon wiadomości.

4) Klasy awaryjne i pomysły na hipotezę

Sieć: opóźnienie/jitter/strata, częściowy spadek portów, komunikacja „flopping” między usługami/PSP.
Komputer/węzły: zabijanie procesów, przegrzanie procesora, wyczerpanie deskryptorów plików, wąskie puli połączeń.
Przechowywanie i baza danych: wzrost dysków opóźnienia, lag repliki, zatrzymać jeden odłamek/lider, podzielić mózg.
Zależności: degradacja zewnętrznych API, ograniczenia dostawcy, 5xx/429 wybuchów.
Zarządzanie zmianą: nieudane zwolnienie, zła flaga funkcji, częściowy wałek.
Obwód: degradacje CDN, dryf DNS/Anycast, awaria ochrony WAF/bot.
Region/AZ: całkowita utrata lub „częściowy” incydent (nieco gorszy i nieprzewidywalny).

5) Narzędzia i techniki

Kubernetes: Chaos Mesh, Litmus, Pow Seal, kube-małpa.
Chmury: AWS Fault Injection Simulator (FIS), Domeny usterek w pobliżu chmur.
Sieć/serwer proxy: Toksyproksy (trucizna TCP), tc/netem, iptables, błąd wysłannika (opóźnienie/przerwanie), zastrzyk usterki Istio.
Procesy/węzły: 'stress-ng', cgroups/CPU-throttle, disk fill.
Trasa ruchu: wagi GSLB/DNS, przełączanie kanaryjskie/niebiesko-zielone do fałszywych kontroli.

6) Przykładowe skrypty (Kubernetes)

6. 1 Opóźnienie/przerwanie trasy (Istio VirtاService)

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 }

Hipoteza: terminy klienta/przekaźniki i BC będą miały p95 <300 ms i częstość błędów <0. 5%.

6. 2 Kill Pod (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"

Hipoteza: balancer i HPA kompensują utratę jednego przypadku bez wzrostu p99> 20%.

6. 3 Chaos sieciowy (opóźnienie w bazie danych)

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"

Hipoteza: puli/timeouts/cache zmniejszy wpływ; p95 płatności pozostaną ≤ SLO.

6. 4 Napełnianie dysku

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"

Hipoteza: rotacja kłód/kwot/wpisów będzie działać przed degradacją tras.

7) Eksperymenty poza K8s

7. 1 Toksyproksy (lokalna/integracja)

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. Usterka 2 wysłannika HTTP (obwód/oczko)

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 (przykład pomysł)

Eksperyment „zabić” N% EC2 w Auto Scaling Group, sztucznie podnieść EBS-latency, wyłączyć NAT-GW w jednym AZ.
Wbudowane kryteria stop dla metryk CloudWatch SLO.

8) Wskaźniki obserwowalności podczas chaosu

SLO/SLI: ułamek dobrych wniosków, p95/p99, szybkość spalania.
Model RED dla tras krytycznych (wskaźnik, błędy, czas trwania).
Baseny: czeka na połączenie p95, wykorzystanie.
DB: lag repliki, zamki, drift p95 żądania.
Sieć: retransmitty, RTT, zachowanie dscp/ecn.
Business SLI: sukces transakcji (depozyty/czeki),% zwrotów/błędów.
Śledzenie: ścieżki selektywne (przykłady), korelacja adnotacji uwalniania.

9) Integracja z SLO/Error-budget

Planowanie eksperymentów w budżecie błędów: chaos nie powinien „zakłócać” celów kwartalnych.
Alerty spalania jako automatyczny wyłącznik.
Raport: „Ile spalił budżet”, „jakie odchylenia w stanie stacjonarnym”.

10) Dni gry (ćwiczenia)

Scenariusz: krótka legenda (np. „Region-Wschód stracony”), wtryskarki, cele SLO, role, czas.
Ocena: RTO/RPO rzeczywiste, jakość komunikacji, prawidłowość książki startowej.
Retro: lista ulepszeń z właścicielami i terminów, aktualizacja dokumentacji/desek rozdzielczych.

11) Automatyzacja i CI/CD

Chaos dymu: krótkie testy na każdym zwolnieniu (np. 1 pod-kill + 200 ms opóźnienia na trasę).
Noc/Tygodnik: Cięższe scenariusze (5-15 min) z raportem.
Bramki promocyjne: jeśli p95/błędy> próg na kanarka - auto-rollback.
Repozytoria z katalogiem eksperymentów (YAML + runbook + progi SLO).

12) Anty-wzory

„Łamanie żywności bez poręczy”: bez kryteriów stop, bez dyżurów → ryzyko rzeczywistego incydentu.
Jednorazowe działanie zamiast procesu.
Chaos bez stanu stacjonarnego: Nie wiadomo, co liczy się jako sukces/porażka.
Nadmierne przekłady → self-DDoS podczas wstrzykiwania opóźnień.
Ignorowanie business SLI: „Technarian” sukces, gdy płatności/zlecenia nie powiodą się.
Brak właścicieli post-analiz i ulepszeń.

13) Lista kontrolna wdrażania (0-45 dni)

0-10 dni

Zdefiniuj SLI stanu stacjonarnego (użytkownik + biznes).
Wybierz narzędzie (Chaos Mesh/Litmus/Toxiproxy/FIS).
Opisz balustrady: promień wybuchu, kryteria zatrzymania, okna, role.

11-25 dni

Uruchom pierwsze eksperymenty: pod-kill, 100-200 ms delay per critical upstream, spadek 1% pakietów.
Konfiguracja alarmów o szybkości spalania, powiązanie wyłącznika z kryteriami zatrzymania.
Spędzić pierwszy dzień gry, zbierać retro i poprawki.

26-45 dni

Dodaj skrypty poziomu AZ/zależności (zewnętrzny PSP, DB-lag).
Zautomatyzuj nocny chaos na postoju; przygotować „sezonowe” scenariusze (szczyty).
Katalog eksperymentów i regularne sprawozdania dotyczące zarządzania/SRE.

14) Wskaźniki zapadalności

≥ 80% tras krytycznych posiada opisane eksperymenty i wskaźniki stanu stacjonarnego.
Automatyczny wyłącznik zabijania jest uruchamiany po przekroczeniu progów p99/błędu.
Kwartał - poziom dnia gry AZ/region; ≥ 1 razy/miesiąc - scenariusz docelowy zależności.
MTTR zmniejsza się po cyklu ulepszeń, zmniejsza się korelacja „uwalniania”.
Odsetek „nieoczekiwanych” spadków w rzeczywistych awariach → ma tendencję do zera.
Deski rozdzielcze wykazują „odporność” jako KPI (szybkość spalania, czas odzysku, odsetek udanych działań DR).

15) Przykłady barier ochronnych i wyłączników

Zatrzymaj się na: 'http _ req _ failed> 1%' 3 minuty, 'p99> 1000 ms' 3 windows, 'deposit _ success <99. 5%`.
Zmniejszenie promienia wybuchu: auto-rollback manifestu, powrót ciężarów GSLB, wyłączanie wtrysków usterek.
Polecenie Stop: pojedynczy przycisk/skrypt z rejestrowaniem przyczyn.

16) Kultura i procesy

Chaos jest częścią rytmu SRE, a nie „ekstremalnym”.
Przejrzyste sprawozdawczość, rozpoznawanie wrażliwości, działania naprawcze.
Szkolenia dyżurne, symulowanie komunikacji z klientami/partnerami.
Powiązanie z SLA/SLO i budżetami: Chaos powinien zwiększyć niezawodność, a nie podważyć.

17) Wniosek

Chaos Engineering zamienia „nadzieję na dziewiątki” w możliwą do udowodnienia trwałość. Formułować stan stacjonarny, umieścić balustrady, złamać małe i kontrolowane, obserwować SLO i biznesowe SLI, rekordowe i automatyczne ulepszenia. Wtedy prawdziwe awarie staną się kontrolowanymi zdarzeniami: przewidywalnym RTO, chronionym budżetem błędów i gotowością zespołu do działania bez paniki.