Chaos Engineering

Первое впечатление о chaos engineering у людей обычно одно: «вы что, прод ломаете намеренно?». Если упростить тезис до этого — да, ломаем. Но между «давайте сломаем что-нибудь» и «у нас есть гипотеза, мы её проверяем контролируемой инъекцией, измеряем SLI до и после, делаем вывод» — пропасть. Первое — внеплановая авария. Второе — chaos engineering. Лист про вторую часть. Соседний лист к Resilience Patterns: там — что строим, здесь — как проверяем, что построенное работает.

Что должен уметь

Главный навык на уровне L4 — формулировать гипотезу о нормальном состоянии (steady-state hypothesis). Именно она отличает эксперимент от аварии: до начала ты пишешь «при инъекции X метрика Y останется в пределах Z». Гипотеза не записана до старта — это не chaos engineering. Я наблюдаю, что команды часто пропускают этот шаг («ну ясно же, что сервис должен жить») и потом не могут сказать, доказал эксперимент хоть что-нибудь или нет.

Понимает, что такое chaos engineering и где проходит граница с обычной поломкой прода; знает Principles of Chaos Engineering; участвует в game day своей команды.
Знает основные режимы отказа своего сервиса: отвалилась зависимость, выросли задержки в сети, кончились ресурсы, убит инстанс, потерян регион. Готов воспроизвести их в dev и staging.

Проводит эксперименты в staging: формулирует гипотезу о нормальном состоянии, выбирает переменные (задержка, доля ошибок, убийство зависимости), задаёт явный радиус поражения (blast radius), измеряет SLI до и после, записывает находки.
Пользуется инструментами под свой стек: Chaos Mesh или Litmus в k8s; AWS Fault Injection Service и Azure Chaos Studio для облачных нагрузок; Chaos Toolkit, когда эксперимент описывается декларативно. Не «руками через iptables и kill».

Превращает game day в регулярный ритуал команды: квартальный календарь, сценарии из прошлых инцидентов и известных дыр, критерии успеха, чеклист по observability, разбор после игры с задачами на выходе.
Запускает chaos в проде с минимальным радиусом: процент трафика, один инстанс, один регион; автоматическая остановка по сигналам мониторинга; явный runbook на уборку и откат. Только после уверенных прогонов в staging.
Связывает chaos с SLO и error budget: эксперименты ставятся, пока в бюджете есть запас, а результаты возвращаются в планирование целей.

L6+

Внедряет непрерывный chaos: автоматические эксперименты в конвейере CI/CD, постоянное отключение случайных инстансов в проде, как у Netflix, общие правила на уровне организации.
Принимает стратегические решения: где chaos спорит с целями по доступности, что об этом думает регулятор (у банков, медицины и платежей свои правила), кто отвечает за ущерб.

Материалы

Книги

Casey Rosenthal, Nora Jones — Chaos Engineering: System Resiliency in Practice (O’Reilly, 2020). Каноническая книга от авторов Principles of Chaos: главы про гипотезы, управление радиусом поражения и устройство game day, кейсы из Netflix, LinkedIn, Capital One, Slack. Не читал — лежит в списке по совету коллег, которые занимаются chaos engineering всерьёз.
Russ Miles — Learning Chaos Engineering (O’Reilly, 2019). Прикладное руководство на Chaos Toolkit. Не читал, поэтому ранжировать не берусь; в списке она как единственная книга, которая идёт от инструмента, а не от принципов.

Статьи и доклады

Principles of Chaos Engineering (2015). Основополагающий документ от команды Netflix, которым дисциплина и была формально названа. Рекомендую начинать с него: он короткий, читается за десять минут, и дальше уже видно, нужен ли остальной список.
Netflix Tech Blog — Chaos Engineering Upgraded (2015). История эволюции от Chaos Monkey к ChAP. Рекомендую вторым шагом после манифеста: там же главный кейс этого листа — см. ниже.
Casey Rosenthal — Principles of Chaos Engineering (SREcon17 Americas). Доклад одного из авторов манифеста: откуда взялись принципы и почему эксперимент ставится именно в проде. Сам не смотрел, оставляю как первоисточник к манифесту выше.
Kelly Shortridge, Aaron Rinehart — Security Chaos Engineering (O’Reilly, 2023). Тот же метод, направленный на защитные механизмы: их проверяют экспериментом, а не бумажным аудитом. Не читал; строка стоит здесь как указатель на смежную ветку метода.

Инструменты

Chaos Mesh (CNCF, родной для k8s) — эксперимент описывается через CRD: PodChaos, NetworkChaos, IOChaos, StressChaos. Сам не пробовал; коллеги, которые ставили эксперименты всерьёз, в сценариях с k8s чаще берут именно его.
Litmus (CNCF, k8s) — альтернатива Chaos Mesh с богатым каталогом готовых экспериментов (ChaosHub) и связкой с Argo Workflows. Тоже знаю по чужим рекомендациям, а не по своим прогонам.
AWS Fault Injection Service / Azure Chaos Studio — управляемый chaos внутри самого облака: погасить инстанс, приостановить диск, придушить API, порвать сеть. Своего оператора разворачивать не надо. С обоими сервисами я не знаком.
Chaos Toolkit — open-source описание экспериментов в JSON и YAML, поверх разных платформ. Берут, когда инструмент не должен быть привязан к одной среде исполнения; в руках у меня он не был.
Gremlin / Steadybit — коммерческие платформы. Надёжная автоматическая остановка по SLO, визуальный конструктор экспериментов, журнал аудита для регуляторов. Ни одну из двух вживую не видел, сужу по описаниям.
Pumba — chaos для Docker: pause, kill, netem, нагрузка на ресурсы в локальных контейнерах. Лёгкий вариант для экспериментов на машине разработчика, хотя сам я до него не добрался.

Best practices

Главный публичный кейс — Netflix: от Chaos Monkey к ChAP. Chaos Monkey запустили в 2010 году с простой идеи: выключим случайный инстанс в проде, посмотрим, что упадёт. Подход шокировал многих, включая их собственную команду. Но через пять лет в заметке «Chaos Engineering Upgraded» (2015) Netflix прямо признал: убивать случайные инстансы оказалось мало. Дальше была ChAP (Chaos Automation Platform) — с явными гипотезами, управлением радиусом поражения, автоматической остановкой по SLI. То есть канонический кейс самой идеи сам прошёл путь от «сломаем что-нибудь» к «проверим гипотезу». Если читаете этот лист и впервые сталкиваетесь с chaos engineering — сначала заметка Netflix 2015 года, потом сюда.

Отсюда три правила, на которых держится вся практика.

Эксперимент начинается с гипотезы, а не с инъекции. Порядок такой: снять базовые метрики нормального состояния, написать гипотезу «при инъекции X метрика Y останется в пределах Z», сделать инъекцию, сравнить с базой, превратить находки в задачи. Гипотеза не записана до старта — это не chaos engineering. Это авария, которой задним числом придумали смысл.

Дальше — маршрут: dev, staging, потом процент продового трафика или один инстанс в одном регионе, и на каждом шаге явные критерии перехода к следующему. Первый chaos сразу в проде — это просто инцидент. После него команда теряет доверие к практике, и вернуть его дороже, чем было бы подождать один квартал.

Третье правило про остановку. Эксперимент прерывается автоматически по сигналу от мониторинга — скорость сжигания бюджета, всплеск ошибок, p99 выше порога, — а не «оператор нажмёт кнопку». Пока оператор осознаёт и реагирует, клиенты уже всё почувствовали. Пробы в Litmus, откатные хуки в Chaos Toolkit, условия остановки в Gremlin — это умеют все.

Game day — это ритуал, а не разовая активность для галочки в OKR. «Провели один game day год назад, отметились» — так культура не строится и новые дыры не находятся. Норма — раз в квартал или раз в N спринтов, со сменой сценариев (сеть, зависимости, ресурсы, регион, человеческий фактор), с разными ролями у дежурных и с разбором после. И всё это в общем календаре, иначе не случится.

Мониторинг — предусловие, а не «подтянем по ходу». Я регулярно вижу попытки начать chaos и параллельно допилить observability. Без метрик, трейсов и логов эффект эксперимента просто не виден: критерий «измерить» проваливается, выводов нет. Готовность выглядит так: SLI и SLO определены, дашборды собраны, алерты работают, runbook’и существуют. Это проверка на входе, а не задача в параллель.

Культурные предусловия — режим blameless, error budget и живые runbook’и. Я наблюдаю чёткое разделение: там, где эти три практики работают, chaos приживается; там, где нет, он либо не приживается, либо после первой найденной дыры превращается в поиск виноватых. Эксперимент найдёт реальную проблему — это его цель. Если в команде за сбои наказывают, обратная связь ломается: находка становится вопросом «кто виноват», и chaos перестаёт быть инструментом. Порядок такой: постмортем без поиска виноватых → error budget → chaos.

Отдельно про связь с бюджетом ошибок: chaos сам его тратит. Я держусь простого правила — запускать, пока в бюджете остаётся не меньше половины запаса; для рискованных экспериментов планка выше, три четверти; при горящем бюджете эксперименты в проде не ставятся вообще. Спор тогда идёт не «можно ли запускать», а «есть ли запас», и это снимает с решения вкусовщину.

И граница, без которой практику продают как универсальную. Chaos бесполезен там, где устойчивости ещё нет: если у сервиса одна реплика, нет ретраев, таймаутов и запасного пути, эксперимент подтвердит очевидное и не даст ничего, кроме простоя. Сначала механизмы — Resilience Patterns, — потом их проверка. Вторая граница организационная: в командах, где нет дежурства и разбора инцидентов, находки эксперимента некому обрабатывать, и они оседают в вики.

Связанные листья

Resilience Patterns — там строят, здесь проверяют. Chaos отвечает на вопросы: circuit breaker реально открывается? ретраи с выдержкой не усиливают шторм? отсеки изолируют?
SLO Engineering — SLO как база отсчёта и как предохранитель. Гипотеза формулируется в терминах SLI; запас бюджета определяет, можно ли вообще ставить эксперимент.
Capacity Planning — chaos проверяет допущения модели мощностей: пороги насыщения, бюджет запаса, скорость реакции автомасштабирования. Без него эти числа «по ощущениям».
CI/CD — непрерывный chaos живёт отдельным этапом конвейера, сценарии game day автоматизируются; неизменяемые артефакты дают быстрый откат после эксперимента.
Incident Response — chaos готовит команду к настоящим инцидентам: проход по runbook доводится до автоматизма, IC получает практику там, где цена ошибки мала.
Blameless Postmortem — находки game day проходят через тот же разбор; культурное предусловие для всей практики.
Runbooks — game day проверяет runbook’и: шаги не сработали — значит, runbook устарел.
Severity Classification — сценарии игр варьируются по уровню и тренируют навык честно назначать severity.
Security Chaos Engineering — тот же метод, объект — механизмы защиты вместо свойств надёжности: проверяем, срабатывает ли обнаружение и реакция, а не остаётся ли система живой.
Game Day / Chaos Drills — chaos engineering проверяет гипотезы о системе; game day тренирует команду. Инструменты общие, охват разный: непрерывные автоматические эксперименты против запланированных учений.
DR Policy & Stakeholders — учения по восстановлению (переключение региона, отказ базы, потеря датацентра) — те же эксперименты верхнего уровня; здесь про метод, там про политику и карту стейкхолдеров, под которые они проводятся.

Открытые вопросы

Security Chaos Engineering уехал в отдельный лист (Practices / Information Security, см. «Связанные листья»). Остался Failure Modes Catalog (TBD) — систематический каталог известных режимов отказа сервиса, из которого потом растут сценарии экспериментов.

Я не знаю, как корректно делать chaos в отраслях под регулированием — банки, медицина, платежи. Требования Federal Reserve, FDA и PCI DSS накладывают ограничения, а публичной литературы про такую практику в банках я не видел. Если есть опыт — расскажите PR’ом.