Chaos Engineering: стійкість систем

Chaos Engineering: стійкість систем

1) Навіщо хаос-інженерія

• перевірити гіпотези про поведінку системи і валідувати SLO;
• виявити приховані SPOF, невірні таймаути/ретраї, каскадні ефекти;
• потренувати команди: game-days, відпрацювання runbook'ів, комунікацій;
• формувати культуру «стійкість за замовчуванням», а не «сподіваємося на краще».

Важливо: Chaos Engineering ≠ «ламати все». Це науковий метод: steady-state → гіпотеза → експеримент → висновки → поліпшення.

2) Базовий цикл експерименту

1. Steady-state (базова лінія): які SLI стабільні? (наприклад, успіх ≤500 мс в 99. 95%).
2. Гіпотеза: при втраті однієї AZ p95 зросте <10%, а доступність ≥99. 9%.
3. Експеримент: спланований фолт з обмеженим blast radius і stop-критеріями.
4. Спостереження: метрики/трейси/логи, burn-rate SLO, бізнес-SLI (наприклад, успішні депозити).
5. Поліпшення: фіксуємо знахідки, змінюємо таймаути/ліміти/маршрутизацію, оновлюємо runbook.
6. Автоматизація/регрес: повторюємо в розкладі, додаємо в CI/CD і календарі game-days.

3) Перила безпеки (safety first)

Blast radius: починаємо з вузького - один pod/інстанс/маршрут/namespace.
Guardrails: алерти на SLO burn-rate (швидкий/повільний), ліміти ретраїв, обмеження QPS, бюджет інциденту.
Stop-критерії: «якщо error-rate> X% або p99> Y мс N хвилин - миттєво stop і rollback».
Вікна: робочі години on-call, повідомлені стейкхолдери, заморожені релізи.
Комунікація: IC/Tech lead/Comms, чіткий канал (War-room), шаблон повідомлень.

4) Класи відмов та ідеї гіпотез

Мережа: затримка/джиттер/втрати, частковий дроп портів, «флапаюча» зв'язок між сервісами/PSP.
Комп'ютер/вузли: вбивство процесів, перегрів CPU, вичерпання файлових дескрипторів, вузькі пули з'єднань.
Сховища та БД: зростання latency дисків, lag реплік, стоп одного шарда/лідера, split-brain.
Залежності: деградація зовнішніх API, ліміти провайдерів, 5xx/429 сплески.
Управління змінами: невдалий реліз, поганий фіча-прапор, partial rollout.
Периметр: CDN деградує, DNS/Anycast дрифт, збій WAF/бот-захисту.
Регіон/AZ: повна втрата або «частковий» інцидент (трохи гірше і непередбачувано).

5) Інструменти та техніки

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Хмари: AWS Fault Injection Simulator (FIS), Fault Domains біля хмар.
Мережа/проксі: Toxiproxy (TCP-яд), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Процеси/вузли: `stress-ng`, cgroups/CPU-throttle, disk fill.
Трафік-маршрутизація: GSLB/DNS weights, canary/blue-green перемикання для фейловер-перевірок.

6) Приклади сценаріїв (Kubernetes)

6. 1 Delay/abort на маршруті (Istio VirtualService)

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 }

Гіпотеза: клієнтські таймаути/ретраї і CB утримають p95 <300 мс і error-rate <0. 5%.

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

Гіпотеза: балансувальник і HPA компенсують loss одного екземпляра без зростання p99> 20%.

6. 3 Мережевий хаос (затримка до БД)

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"

Гіпотеза: пули/таймаути/кеш знизять вплив; p95 платежів залишиться ≤ SLO.

6. 4 Заповнення диска

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"

Гіпотеза: ротація логів/квоти/алерти спрацюють до деградації маршрутів.

7) Експерименти поза K8s

7. 1 Toxiproxy (локальний/інтеграційний)

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. 2 Envoy HTTP fault (периметр/mesh)

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 (приклад ідеї)

Експеримент «вбити» N% EC2 в Auto Scaling Group, штучно підняти EBS-latency, відключити NAT-GW в одній AZ.
Вбудовані стоп-критерії за CloudWatch SLO-метриками.

8) Метрики спостережуваності під час хаосу

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
RED-модель за критичними маршрутами (Rate, Errors, Duration).
Пули: очікування з'єднання p95, utilization.
БД: lag реплік, locks, дрейф p95 запитів.
Мережа: retransmits, RTT, dscp/ecn поведінка.
Бізнес-SLI: успіх транзакцій (депозити/чекаут),% повернень/помилок.
Трасування: вибіркові трейси (exemplars), кореляція реліз-анотацій.

9) Інтеграція з SLO/Error-budget

Плануйте експерименти в рамках бюджету помилок: хаос не повинен «зривати» квартальні цілі.
Burn-rate алерти як автоматичні kill-switch.
Звітність: «скільки бюджету спалили», «які девіації steady-state».

10) Game-days (навчання)

Сценарій: коротка легенда (наприклад, «регіон-East втрачений»), кроки ін'єкцій, цілі SLO, ролі, час.
Оцінка: RTO/RPO фактичні, якість комунікацій, коректність runbook.
Ретро: список поліпшень з власниками і термінами, оновлення документації/дашбордів.

11) Автоматизація та CI/CD

Smoke-chaos: короткі тести на staging при кожному релізі (наприклад, 1 pod-kill + 200 мс delay на один маршрут).
Нічні/щотижневі: більш важкі сценарії (5-15 хв) зі звітом.
Промо-гейти: якщо р95/помилки> порогу на canary - авто-відкат.
Репозиторії з каталогом експериментів (YAML + runbook + SLO-thresholds).

12) Анти-патерни

«Ламати прод без перил»: немає stop-критеріїв, немає on-call → ризик цього інциденту.
Одноразова акція замість процесу.
Хаос без steady-state: незрозуміло, що вважати успіхом/провалом.
Надлишкові ретраї → само-DDoS при ін'єкції затримок.
Ігнорування бізнес-SLI: «технарські» успіхи при провалі платежів/замовлень.
Відсутність пост-аналізу і власників поліпшень.

13) Чек-лист впровадження (0-45 днів)

0-10 днів

Визначити steady-state SLI (користувацький + бізнес).
Вибрати інструмент (Chaos Mesh/Litmus/Toxiproxy/FIS).
Описати перила: blast radius, stop-критерії, вікна, ролі.

11-25 днів

Запустити перші експерименти: pod-kill, 100-200 мс delay на критичний апстрім, drop 1% пакетів.
Налаштувати burn-rate алерти, зв'язати kill-switch зі stop-критеріями.
Провести перший game-day, зібрати ретро і фікси.

26-45 днів

Додати сценарії рівня AZ/залежностей (зовнішній PSP, БД-lag).
Автоматизувати nightly-хаос на staging; готувати «сезонні» сценарії (піки).
Каталог експериментів і регулярні звіти для керівництва/SRE.

14) Метрики зрілості

≥80% критичних маршрутів мають описані експерименти і steady-state метрики.
Авто kill-switch спрацьовує при перевищенні порогів p99/error-rate.
Щокварталу - game-day рівня AZ/регіон, ≥1 раз/міс - цільовий сценарій залежностей.
MTTR знижується після циклу поліпшень, кореляція «реліз ↔ інцидент» зменшується.
Частка «несподіваних» падінь при реальних збоях → прагне до нуля.
Дашборди показують «стійкість» як KPI (burn-rate, час відновлення, частка успішних DR-дій).

15) Приклади guardrails і тригерів stop

Stop при: 'http _ req _ failed> 1%'3 хвилини,'p99> 1000 мс'3 вікна,'deposit _ success <99. 5%`.
Зниження blast radius: авто-відкат маніфесту, повернення ваг GSLB, відключення fault-ін'єкцій.
Команда stop: єдина кнопка/скрипт з логуванням причин.

16) Культура і процеси

Хаос - це частина SRE-ритму, не «екстрим».
Прозорі звіти, визнання вразливостей, коригувальні дії.
Навчання on-call, симуляції комунікацій з клієнтами/партнерами.
Ув'язка з SLA/SLO і бюджетами: хаос повинен підвищувати, а не підривати надійність.

17) Висновок

Chaos Engineering перетворює «надію на дев'ятки» в доказову стійкість. Формулюйте steady-state, ставте перила, ламайте мале і контрольоване, спостерігайте SLO і бізнес-SLI, фіксуйте і автоматизуйте поліпшення. Тоді реальні збої стануть керованими подіями: передбачуваний RTO, захищений error-budget і готовність команди діяти без паніки.