Chaos Engineering

1) Базові принципи

Steady State як вихідна гіпотеза. Ясно визначте норму (наприклад: p95 < 200 мс, error rate < 0. 3%, успішність критичного флоу> 99. 5%).
Ізольовані змінні. Змінюйте по можливості один фактор за раз, щоб причинно зв'язати ефект і поліпшення.
Градусність. Починаємо з малих амплітуд в безпечному середовищі → розширюємо охоплення і інтенсивність.
Guardrails. Явні стоп-умови по SLO/алертам/бюджету помилок.
Повторюваність. Експеримент повинен бути детерміновано відтворюємо (скрипти/маніфести/IaC).
Етика та безпека. Ніяких реальних персональних даних і фінансових транзакцій в ризикових експериментах.

2) Що таке «стійкий стан»

• Латентності p50/p95/p99 ключових ендпоінтів.
• Частка успішних транзакцій і конверсія критичних шляхів.
• Error rate, таймаути, частка «shed» запитів (відсічених при насиченні).
• Швидкість самовідновлення (MTTR), стійкість до ретрай (без штормів).
• Інваріанти домену: відсутність «мінусів у балансі», одноразово виконані виплати, консистентність звітної доби тощо.

3) Каталог ін'єкцій (що «ламаємо»)

Мережа: затримка, джиттер, втрата/дублікати, обмеження пропускної здатності, TLS-обриви, DNS-флаппінг.
Обчислення: перевантаження CPU, тиск на пам'ять/GC, вичерпання дескрипторів, clock skew.
Сховище: високі p95 I/O, ENOSPC, відмова лідера/репліки, split-brain, затяжні fsync.
Залежності: 5xx/429, «повільний успіх», деградація зовнішніх API, rate-limit.
Дані: дублі/пропуски повідомлень, out-of-order, «брудні» записи, конфлікт версій.
Операції: невдалий реліз/конфіг, фіча-прапор з багом, закінчився сертифікат, ротація ключа.
Люди і процеси: недоступність відповідальних, затримка ручного апрува, невірний runbook.

4) Дизайн експерименту (шаблон)

1. Гіпотеза: «При + 300 мс до валютного сервісу p99 основного API <450 мс, відкривається брейкер, віддається stale-відповідь ≤ 15 хвилинної давності».
2. Ін'єкція: профіль відмови (тип/амплітуда/тривалість) і цільовий контур.
3. Метрики/лог-теги: маркування'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: abort при'error _ rate> 2%'або p99> SLA × 2 більше 1 хвилини.
5. Результати/висновок: список спостережень, багів, поліпшень, план робіт і повторний прогін.

5) Спостережуваність: що обов'язково

Трейсинг: шлях запиту через залежності; сегменти з деградацією позначені.
Метрики ресурсів: CPU, heap/GC, FD, дискові IOPS/lat, мережевий bandwidth, глибина черг.
Бізнес-метрики: конверсія/успіх операцій, частка компенсованих транзакцій.
Логи подій: відкриття/закриття брейкерів, ретраї та їх бюджет, перемикання лідера БД.
Панель експерименту: live-дашборд з порогами guardrails і «червоною кнопкою» аборту.

6) Guardrails і безпека

Технічні: верхні межі error rate/latency, падіння частки успішних операцій, зростання DLQ.
Організаційні: вікно часу, залучений on-call, принцип «одна зона - один експеримент».
Дані/комплаєнс: тільки синтетика або знеособлені набори; заборона тестів, що ведуть до порушення регуляторики.
Відкат: готова процедура rollback/disable прапора/м'якого drain трафіку.

7) Патерни стійкості, які повинні проявитися

Таймаут-бюджети і джитерні ретраї (без штормів).
Circuit Breaker з напівускриттям (half-open) і експоненціальним відновленням.
Bulkheads: ізоляція пулів за критичністю (платежі vs аналітика).
Backpressure и rate-limit: передбачувана відсічка низького пріоритету.
Кеш з coalescing, захист від «штормів прогріву».
Ідемпотентність побічних ефектів і саги з компенсуючими діями.
Кворуми, фейловер і анти-ентропія для відновлення даних.

8) Приклади сценаріїв (скетчі)

8. 1 Повільна залежність (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 Втрата лідера БД

Ін'єкція: зупинка лідера/примусове перевибори.
Очікування: тимчасова заборона записів, читання з кворуму, збереження WAL/Outbox, авто-відновлення реплікації, відсутність подвійного запису.

8. 3 ENOSPC на лог-диску

Ін'єкція: заповнення диска до 95-100%.
Очікування: аварійна ротація логів, збереження критичних журналів, відключення некритичних фіч, алерт і авто-ремедіація.

8. 4 Burst-трафік + шейдинг

Ін'єкція: × 3 RPS на 5 хвилин по гарячому ендпоінту.
Очікування: відкидання низького пріоритету, стабільний p95 «ядра», відсутність каскаду ретраїв.

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

Chaos-smoke в стейджі для кожного релізу (короткі ін'єкції на безпечних амплітудах).
Нічні прогони по каталогу експериментів (матриця сервіси × види відмов).
Гейти: реліз блокується, якщо «стійкість нижче порога» (наприклад, частка успішних fallback <95%).
Артефакти: звіт, трейси, флеймграфи CPU/heap, снапшоти метрик і конфігів.

10) Гейм-дні (Game Days)

• Ролі: провідний експерименту, спостерігач метрик, оператор відкату, представник бізнесу.
• Сценарії: деградація кешу, часткова відмова AZ/регіон-фейловер, «поганий реліз», недоступність зовнішнього провайдера.
• Результати: знайдені прогалини в runbook, поліпшення алертів, коригування SLO і бюджетів ретраїв.

11) Хаос для даних, подій і ML

Потоки даних: тести на дублікати, пропуски, out-of-order, затримки; перевірка ідемпотентних консюмерів і DLQ-стратегій.
Сховища: деградація індексів, hot-partition, конфлікт блокувань, реплікація під лагом.
ML: затримка фіч-стора, відкат на baseline-модель, погіршення якості вхідних даних (drift) - система повинна «м'яко тупіти», а не падати.

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

Хаос без спостережуваності: ви «сліпі», висновки спекулятивні.
Ін'єкції відразу в проді без стейджа і гвард-рейлів.
«Один великий експеримент» на все відразу - неясно, що саме спрацювало.
Безсистемні хаос-акції без гіпотез і ретесту після фіксів.
Зосередженість тільки на інфраструктурі - забуті бізнес-інваріанти.
Ігнорування людей/процесів: альберти, on-call, runbook - частина системи.

13) Зрілість практики (модель)

1. Ad-hoc: разові ін'єкції локально.
2. Стейдж-хаос: каталог сценаріїв, повторювані прогони, дашборди.
3. Реліз-хаос: smoke-хаос в кожному релізі, гейти, звіти.
4. Прод-хаос з обмеженнями: малий трафік, строгі guardrails, готовий відкат.
5. Безперервна стійкість: авто-експерименти, SLO-управління, поліпшення як потік робіт.

14) Інтеграція з архітектурними практиками

Тестування стійкості: хаос-експерименти доповнюють fault-ін'єкції і сценарії деградації.
Навантажувальне тестування: комбіновані експерименти «навантаження + відмова» виявляють каскади і шторм ретраїв.
Policy as Code / RBAC/ABAC: guardrails, кроки відкату і ліміти оформляйте як політики.
Управління згодою/приватністю: не допускайте експериментів, які порушують режим обробки даних.
Geo-архітектура: хаос-перевірки фейловера регіонів і прив'язки даних до юрисдикцій.

15) Міні-рецепти (псевдокод)

Брейкер + деградація

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

Лімітер + шейдинг

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

Ідемпотентний побічний ефект

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

16) Чек-лист архітектора

1. Визначені Steady State і guardrails?
2. Є каталог сценаріїв (мережа/CPU/сховище/залежності/дані/операції)?
3. Спостережуваність покриває ресурси, хвости латентності, бізнес-інваріанти?
4. Таймаути/ретраї/брейкери/лімітери/bulkheads включені і параметризовані?
5. Підготовлені runbook і «червона кнопка»?
6. Є хаос-smoke в стейджі і nightly-експерименти?
7. Прописані «безпечні» вікна і ролі на гейм-дні?
8. Експерименти відтворюються (IaC/скрипти), результати версіонуються?
9. Поліпшення фіксуються завданнями, робиться ретест?
10. Охоплені дані і ML-конвеєри, не тільки HTTP?

Висновок

Chaos Engineering перетворює «непередбачені інциденти» в передбачувані сценарії. Гіпотеза стійкості, контрольовані ін'єкції, жорсткі guardrails, багата спостережуваність і дисципліна ретестів - це інструменти, які знижують ризик релізів і підвищують довіру до платформи. У підсумку команда розуміє межі системи, вміє елегантно деградувати і швидко повертати сервіс користувачеві навіть в умовах відмов.