chaos-engineering.js·5 scenarios
Chaos engineering concept page — Netflix-origin (Chaos Monkey 2010), 4 Principles of Chaos (steady-state hypothesis, real-world events, prod, blast radius), tools (Chaos Monkey, Chaos Mesh, Litmus, Gremlin, AWS FIS, toxiproxy), maturity levels, game days vs continuous chaos. Topology: 3 AZs in us-east-1 each with svc-a + svc-b, edge group with client + LB, chaos control plane (Gremlin/AWS FIS + steady-state dashboard + big red button rollback). Five scenarios: steady-state baseline, Chaos Monkey kills random instance, AZ network partition, dependency latency injection with retry storm, quarterly game day with runbook findings. ADR-001 on chaos-controller covers when to graduate from staging to prod chaos.
Retries, circuit breakers, timeouts, failovers, multi-AZ deploy — это весь код, который вы написали "на случай если". Пока он не сработал ни разу под нагрузкой, это untested code paths. Реальный инцидент будет первым тестом — и происходить он будет в три часа ночи, на полной нагрузке, с уставшим on-call.
Chaos engineering решает простую проблему: в распределённой системе с десятками сервисов, БД, очередей, регионов и зависимостей никто не способен предсказать, как она поведёт себя при отказе X. Конфигурации, прошивки, версии библиотек, DNS-кеши, лимиты файловых дескрипторов, TLS-сертификаты, NTP — всё это взаимодействует неочевидным образом. Единственный надёжный способ узнать, как система упадёт — сломать её намеренно, в контролируемых условиях, пока вы рядом и готовы откатить.
Это превращает "надежда на лучшее" в "эмпирически подтверждённая устойчивость". И отдельная важная польза — chaos тренирует команду: incident commander, scribe, communication, runbook'и. Когда настоящий инцидент случается, мышцы уже разогреты.
Chaos engineering — это научный эксперимент с гипотезой. Не "ломаю, чтобы посмотреть, что будет", а "проверяю гипотезу: при выпадении AZ-1a метрика успеха не изменится больше чем на 0.1%". Если гипотеза подтвердилась — система устойчива. Если нет — нашли weakness ДО того, как её нашёл клиент.
Четыре принципа из Principles of Chaos (Casey Rosenthal, Nora Jones, Netflix):
Каноничная chaos-инфраструктура для multi-AZ-сервиса.
1a, 1b, 1c), в каждой по паре сервисов svc-a-* (фронт) и svc-b-* (бэкенд). Это типичная двухуровневая архитектура за load balancer'ом.client (реальный пользовательский трафик) и lb (load balancer), который раскладывает запросы по трём AZ.chaos (Gremlin или AWS FIS — control plane инъекций), dashboard (видит steady-state метрики), rollback ("big red button" — автоматический abort).Edges делятся на три класса:
client → lb → svc-a-* → svc-b-*. Обычные продакшн-вызовы.chaos → svc-*. По этим линкам идёт инжекция (kill, latency, partition).svc-* → dashboard, lb → dashboard, dashboard → rollback → chaos. Замкнутый контур: метрики приходят в дашборд, дашборд видит нарушение steady state, дёргает rollback, rollback гасит chaos. Это и есть тот самый "big red button" в железе.Узел chaos несёт ADR-001 — записанное решение, когда промоутить chaos из staging в production. Открой его кликом на узле.
Пять сценариев, расположенных по возрастанию blast radius и риска. Запускать в этом порядке — это и есть путь зрелости.
Прежде чем что-либо ломать, определи метрику здоровья. Сценарий показывает прод-трафик через все три AZ, success-rate 99.97%, p99 180 ms. Это базовая линия, относительно которой ВСЕ остальные эксперименты будут судиться. Без неё chaos бессмыслен: непонятно, что значит "система сломалась".
Оригинальный Netflix Chaos Monkey (2010). Случайно убивает один pod, проверяет, что LB его выкинет из пула и трафик переедет на оставшиеся. На дашборде success-rate проседает до 99.91% на 12 секунд и восстанавливается — гипотеза держится, единичная смерть инстанса невидима для пользователя. Это самый маленький разумный blast radius: 1 из 6 инстансов.
Серьёзнее. iptables DROP между svc-*-1 и остальными AZ — классический split-brain. Инстансы в AZ-1a "видят себя" живыми, но изолированы. LB не сразу это поймёт (health-check проходит локально). Сценарий показывает, как читаются устаревшие данные, success-rate падает до 96.2%, дашборд видит нарушение, rollback срабатывает автоматически и снимает iptables-правила. Action item: zone-aware health checks с глобальным readiness-пробом.
Самый коварный сценарий и обычно — источник самых страшных insight'ов. tc qdisc netem delay 200ms на svc-b-2. Сама по себе небольшая задержка, но клиент-сервис настроен на агрессивные retry без джиттера. Один пользовательский запрос превращается в три downstream-вызова, connection pool к svc-b иссякает, svc-a-2 начинает дропать запросы. Один медленный downstream положил весь сервис через retry-усиление. Action item: jittered exponential backoff, retry budget = 1, hedged requests.
Командное упражнение. Facilitator объявляет сценарий ("AZ us-east-1a падает через 5 минут"), но не говорит, какая именно. Команда работает как при реальном инциденте: IC, scribe, comms. Сценарий находит две вещи, которые невозможно было найти иначе:
Шесть action items за 28 минут. Это сравнимо по эффективности с месяцем гипотетических обсуждений.
Это центральный политический вопрос chaos-практики и причина, почему программу часто закрывают после первого инцидента. Контекст и логика — внутри узла chaos, краткая суть здесь.
Дилемма. Манифест Principles of Chaos требует прод. Реальность: chaos в проде без observability, runbook'ов и blast-radius лимитов = реальный инцидент. Knight Capital 2012 — каноничный пример, как "deploy на 8 серверов из 9" может стоить 440M$ за 45 минут.
Принятое решение. Промоутить chaos из staging в prod по maturity gates, не по календарю.
| Уровень | Где | Условия входа |
|---|---|---|
| 1 | Staging game days, ручные | Команда хочет начать. Достаточно одного человека |
| 2 | Scheduled prod chaos | SLO с error budget + runbook'и + blast-radius caps + sponsor |
| 3 | Continuous prod chaos | Level 2 поймал и пофиксил минимум 2 latent bug'а |
| 4 | Chaos в CI/CD | ChAP-style: новый сервис не идёт в prod без chaos suite |
Counter-rule, который никогда не нарушается. Не запускать chaos в проде во время активного инцидента, во время deploy freeze и когда квартальный error budget уже сожжён. Этих трёх правил достаточно, чтобы не превратить chaos-программу в источник инцидентов.
tc, iptables, kubectl).error-budgets (без него chaos бессмыслен), circuit-breaker (тестируется chaos'ом), jepsen-testing (chaos для распределённых БД).