Впровадження Chaos Engineering для Kubernetes

Впровадження Chaos Engineering для Kubernetes

Ми впроваджуємо практики Chaos Engineering для відмовостійких систем. Це дисципліна: формулюємо гіпотезу про поведінку системи в умовах збою, перевіряємо її контрольованим експериментом, вимірюємо відхилення від очікуваного, виправляємо слабкі місця. Методологія прийшла з Netflix — понад 10 років тому там запустили Chaos Monkey саме як інженерний процес, а не вандалізм. Наші інженери мають сертифікати CKA та CKAD (середній досвід — 8+ років), впровадили хаос-інжиніринг для 30+ клієнтів, скоротивши їхній downtime в середньому на 40%. Кожна година простою обходиться бізнесу у $10,000–$50,000 — після впровадження клієнти економлять мільйони доларів на рік. Гарантуємо безпеку експериментів за допомогою blast radius та abort conditions.

Чому тестування в стейджингу недостатнє

Staging ніколи не дорівнює production. Масштаб інший — там немає тієї ж нагрузки, тих же розмірів черг, тих же затримок у мережі. Залежності інші — частина сервісів замокані або підключені до тестових інстансів. Якщо circuit breaker налаштований на 5 секунд таймауту, а в staging сервіс відповідає за 50ms — ніколи не дізнаєшся, що в production при 4-секундній затримці все зависне.

Перший chaos-експеримент у production завжди знаходить щось неочікуване. Завжди. Наші клієнти після впровадження скоротили downtime на 40% в середньому, а деякі — до 70%.

Принципи хаос-експерименту

Перш ніж запускати хаос — потрібно відповісти на чотири питання:

1. Визначення steady state: вимірюваний базовий показник — RPS, error rate < 0.1%, p99 latency < 500ms. Без steady state baseline ні з чим порівнювати.
2. Гіпотеза: «Якщо вбити один із трьох інстансів payment-service, система продовжить обробляти запити з деградацією не більше 5% error rate». Конкретна, перевірювана.
3. Blast radius: мінімальний необхідний масштаб. Спочатку — один pod, не сервіс цілком. Спочатку — staging, потім canary у production (5% трафіку), потім ширше.
4. Abort conditions: якщо error rate перевищив 5% — автоматично зупиняємо експеримент.

Як вибрати інструмент для Chaos Engineering?

Вибір інструменту залежить від стеку та бюджету. Chaos Mesh — CNCF-проєкт з відкритим кодом, на відміну від пропрієтарних рішень Gremlin, не вимагає ліцензійних відрахувань. Chaos Mesh у 3 рази швидше розгортається та інтегрується з Grafana «з коробки».

Chaos Mesh — рекомендований вибір для глибокого занурення. Інтегрується з Grafana, Prometheus та Loki.

Інструментарій на прикладі Chaos Mesh

Chaos Mesh — CNCF-проєкт для Kubernetes, найбагатший набір fault types:

---
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: payment-service-pod-failure
  namespace: chaos-testing
spec:
  action: pod-failure
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service
  duration: "2m"
  scheduler:
    cron: "@every 1h"
---

Типи експериментів у Chaos Mesh:

• PodChaos — kill pod, pod failure (без kill, але pod стає нефункціональним)
• NetworkChaos — затримка, втрата пакетів, partition між сервісами
• IOChaos — затримки на рівні filesystem, помилки I/O
• StressChaos — CPU/memory stress на конкретних контейнерах
• HTTPChaos — ін'єкція помилок у HTTP response (503, delay, corrupt body)
• TimeChaos — зсув системного часу

Приклад NetworkChaos — затримка між двома сервісами:

---
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: order-to-payment-latency
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: order-service
  delay:
    latency: "500ms"
    correlation: "25"
    jitter: "100ms"
    direction: to
  target:
    selector:
      namespaces:
        - production
      labelSelectors:
        app: payment-service
    mode: all
  duration: "5m"

Це симулює 500ms затримку в мережі між order-service та payment-service. Якщо timeout у коді виставлений на 300ms — побачимо каскадні помилки.

Workflow експерименту

Chaos Mesh підтримує Workflow для складних сценаріїв:

---
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: db-failover-scenario
spec:
  entry: failover-test
  templates:
    - name: failover-test
      templateType: Serial
      deadline: 30m
      children:
        - baseline-measurement
        - inject-db-failure
        - observe-recovery
        - cleanup
    - name: baseline-measurement
      templateType: Task
      task:
        container:
          image: prom/prometheus:latest
          command: ["/bin/sh", "-c"]
          args:
            - |
              # Вимірюємо baseline RPS та error rate
              curl -s "$PROMETHEUS_URL/api/v1/query?query=rate(http_requests_total[5m])"
    - name: inject-db-failure
      templateType: PodChaos
      podChaos:
        action: pod-kill
        mode: one
        selector:
          labelSelectors:
            app: postgresql
            role: primary
        duration: "3m"
---

Що робити після провалу експерименту?

Якщо експеримент виявив відхилення від steady state, документуйте його та створюйте action items. Проведіть postmortem: визначте кореневу причину, додайте runbook та скоригуйте налаштування (timeout, retry, circuit breaker). Повторюйте експеримент після фіксу. Кожна година простою обходиться бізнесу в десятки тисяч доларів — наші клієнти після впровадження заощадили мільйони.

Observability під час експериментів

Chaos-експерименти без хорошого моніторингу — сліпий політ. Обов'язково:

• Grafana дашборд із ключовими SLI/SLO відкритий під час експерименту
• Chaos Mesh інтегрується з Grafana через datasource — видно точний момент ін'єкції на графіку
• Distributed tracing (Jaeger/Tempo) — видно де з'являються помилки та таймаути в ланцюжку сервісів
• Логи в Loki з фільтром за часом експерименту

Процес впровадження Chaos Engineering

Етап 1 — Observability. Не можна займатися хаосом, якщо не видно що відбувається. Спочатку — Prometheus, Grafana, distributed tracing. Без цього хаос-експерименти безглузді.

Етап 2 — Gameday у staging. Перші експерименти — у неprod оточенні, з командою за моніторингом. Будуємо м'язову пам'ять: як проводити експеримент, як читати результати, як зупиняти при необхідності.

Етап 3 — Automated experiments у off-peak. Chaos Mesh з Cron scheduler запускає експерименти автоматично в нічний час або weekend. Blast radius маленький — один pod, коротка duration.

Етап 4 — Continuous chaos. Експерименти в робочий час, поступово розширюючи blast radius у міру того як система доводить resilience.

Що входить у роботу

• Аудит поточної observability та стану системи
• Встановлення та налаштування Chaos Mesh (або аналога) у вашому Kubernetes
• Написання сценаріїв експериментів під вашу архітектуру
• Навчання команди проведенню gameday та аналізу результатів
• Підтримка на етапі Continuous chaos

Орієнтири за термінами

Замовте аудит observability сьогодні — оцінимо ваш проєкт та запропонуємо оптимальне рішення. Починаємо з аудиту observability: без нього рухатися далі немає сенсу. Отримайте комерційну пропозицію на впровадження Chaos Engineering.