🔴 Advanced

Chaos Engineering — Testovanie odolnosti systémov

Chaos engineering je disciplína experimentovania na systéme s cieľom budovať dôveru v jeho schopnosť zvládnuť turbulentné podmienky v produkcii. Namiesto čakania na výpadok ho zámerne vyvoláme — kontrolovane a bezpečne.

Prečo chaos engineering?

Moderné distribuované systémy sú komplexné. Mikroslužby, cloudy, siete — všetko môže zlyhať. Tradičné testovanie (unit, integration, e2e) testuje expected behavior. Chaos engineering testuje unexpected failures.

Netflix to zhrnul najlepšie: "Najlepší spôsob, ako sa vyhnúť zlyhaniu v piatok o 3:00 ráno, je zlyhať v utorok o 10:00 dopoludnia."

Čo chaos engineering NIE je

  • Nie je to "rozbíjanie vecí pre zábavu"
  • Nie je to penetračné testovanie
  • Nie je to testovanie v izolácii
  • Je to vedecký experiment s hypotézou a meraním

Princípy chaos engineering

1. Definujte Steady State

Steady state je normálne, zdravé správanie systému vyjadrené merateľnými metrikami:

  • Response time < 200 ms (p99)
  • Error rate < 0.1 %
  • Throughput > 1000 RPS
  • Dostupnosť > 99.9 %

2. Formulujte hypotézu

"Ak zabijeme jednu inštanciu API serveru, load balancer presmeruje traffic na zdravé inštancie a steady state sa nezmení."

3. Simulujte reálne udalosti

  • Výpadok inštancie / kontajnera / nodu
  • Sieťová latencia alebo packet loss
  • CPU/memory spike
  • Výpadok externej závislosti (DB, API)
  • DNS zlyhanie

4. Minimalizujte blast radius

Začnite malým experimentom a postupne rozširujte:

Dev → Staging → Canary (malá časť produkcie) → Production

5. Automatizujte experimenty

Chaos experimenty by mali bežať kontinuálne, nie jednorazovo.

Chaos Monkey a Simian Army

Netflix vytvoril Chaos Monkey v 2011 — nástroj, ktorý náhodne zabíja EC2 inštancie v produkcii. Z neho vznikla celá "Simian Army":

Nástroj Čo robí
Chaos Monkey Zabíja náhodné inštancie
Latency Monkey Pridáva sieťovú latenciu
Chaos Gorilla Simuluje výpadok celej AZ
Chaos Kong Simuluje výpadok celého regiónu

Litmus — Kubernetes-native chaos

LitmusChaos je CNCF Incubating projekt pre chaos engineering na Kubernetes. Definuje experimenty ako Kubernetes CRD.

Inštalácia

# Pomocou Helm
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm install litmus litmuschaos/litmus \
  --namespace litmus \
  --create-namespace

Príklad: Pod Delete experiment

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: api-chaos
  namespace: production
spec:
  engineState: active
  appinfo:
    appns: production
    applabel: app=api-server
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"
        probe:
          - name: api-health
            type: httpProbe
            httpProbe/inputs:
              url: http://api-server.production:8080/health
              method:
                get:
                  criteria: ==
                  responseCode: "200"
            mode: Continuous
            runProperties:
              probeTimeout: 5s
              interval: 5s

Príklad: Network chaos

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: network-chaos
spec:
  engineState: active
  appinfo:
    appns: production
    applabel: app=checkout
    appkind: deployment
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            - name: NETWORK_INTERFACE
              value: eth0
            - name: NETWORK_LATENCY
              value: "200"  # ms
            - name: TOTAL_CHAOS_DURATION
              value: "120"
            - name: DESTINATION_HOSTS
              value: "database.production.svc"

Gremlin — Enterprise chaos platform

Gremlin je komerčná platforma s GUI, tímovou správou a bezpečnostnými kontrolami.

Typy útokov v Gremlin

Resource attacks:

  • CPU — zaťaží procesory
  • Memory — spotrebuje RAM
  • Disk — zaplní disk alebo zvýši I/O
  • Process killer — zabije konkrétny proces

Network attacks:

  • Latency — pridá oneskorenie
  • Packet loss — zahodí pakety
  • DNS — simuluje DNS zlyhanie
  • Blackhole — úplne zablokuje traffic

State attacks:

  • Shutdown — vypne inštanciu
  • Time travel — zmení systémový čas
  • Process killer — zabije proces

Gremlin CLI

# CPU attack na 60 sekúnd, 1 jadro
gremlin attack cpu --length 60 --cores 1

# Sieťová latencia 200ms na port 5432 (PostgreSQL)
gremlin attack network latency \
  --length 120 \
  --ms 200 \
  --port 5432

# DNS blackhole
gremlin attack network dns \
  --length 60 \
  --hostnames "api.external-service.com"

Steady State Hypothesis v praxi

Definovanie steady state

# Príklad: Prometheus query pre steady state
steady_state = {
    "http_success_rate": {
        "query": "sum(rate(http_requests_total{status=~'2..'}[5m])) / sum(rate(http_requests_total[5m]))",
        "threshold": ">= 0.999"
    },
    "p99_latency": {
        "query": "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))",
        "threshold": "<= 0.5"  # 500ms
    },
    "error_rate": {
        "query": "sum(rate(http_requests_total{status=~'5..'}[5m]))",
        "threshold": "<= 0.001"
    }
}

Experiment workflow

1. Measure steady state ──► All metrics OK?
                                │
                           Yes  │  No → Fix first!
                                ▼
2. Inject failure ──────► Run experiment
                                │
                                ▼
3. Observe ─────────────► Metrics still OK?
                                │
                    ┌───────────┴──────────┐
                    ▼                      ▼
               Yes: System               No: System
               is resilient              has weakness
                    │                      │
                    ▼                      ▼
            Document &              Fix, improve,
            expand scope            re-test

Game Days

Game Day je organizované cvičenie, kde tím simuluje výpadky a precvičuje incident response.

Priebeh Game Day

  1. Príprava — definujte scenáre, upozornite tímy, pripravte rollback
  2. Briefing — vysvetlite pravidlá, safety measures
  3. Experiment — spustite chaos experiment
  4. Observácia — sledujte dashboardy, alerty, tímovú reakciu
  5. Debrief — čo fungovalo, čo nie, akčné body

Scenáre pre Game Day

  • Výpadok hlavnej databázy
  • DNS zlyhanie pre externú službu
  • 50 % packet loss medzi službami
  • Disk full na logging serveri
  • Certificate expiration

Chaos v CI/CD pipeline

# GitHub Actions — chaos test v staging
chaos-test:
  runs-on: ubuntu-latest
  needs: deploy-staging
  steps:
    - name: Run chaos experiment
      run: |
        litmus run pod-delete \
          --namespace staging \
          --label app=api \
          --duration 60s

    - name: Verify steady state
      run: |
        # Kontrola že API stále odpovedá
        for i in $(seq 1 30); do
          STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://staging-api.example.com/health)
          if [ "$STATUS" != "200" ]; then
            echo "FAIL: API returned $STATUS"
            exit 1
          fi
          sleep 2
        done
        echo "PASS: API survived chaos"

Bezpečnosť chaos experimentov

Safety checklist

  • ✅ Kill switch — možnosť okamžite zastaviť experiment
  • ✅ Blast radius — obmedzte na minimum (1 pod, 1 node)
  • ✅ Time limit — maximálna doba trvania
  • ✅ Monitoring — aktívne sledovanie počas experimentu
  • ✅ Rollback plan — čo robiť ak niečo pokazí
  • ✅ Notifikácia — informujte dotknuté tímy

Best Practices

  1. Začnite v staging — nie v produkcii
  2. Malé kroky — jeden pod, nie celý cluster
  3. Merajte všetko — bez metrík nevieme či experiment uspel
  4. Automatizujte — chaos experimenty v CI/CD
  5. Game Days — pravidelné cvičenia (mesačne)
  6. Dokumentujte výsledky — každý experiment je učenie
  7. Opravte nájdené problémy — chaos bez akcie je zbytočný

Chaos engineering nie je o rozbíjaní vecí — je o budovaní dôvery. Kontrolované experimenty odhaľujú slabiny skôr, než ich odhalia vaši zákazníci o 3:00 ráno.