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, богатая наблюдаемость и дисциплина ретестов — это инструменты, которые снижают риск релизов и повышают доверие к платформе. В итоге команда понимает границы системы, умеет элегантно деградировать и быстро возвращать сервис пользователю даже в условиях отказов.