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). Доклад одного из авторов манифеста: откуда взялись принципы и почему эксперимент ставится именно в проде. Сам не смотрел, оставляю как первоисточник к манифесту выше.
Максим Ивашковский, Андрей Матвеев — Сломай меня полностью: Chaos Engineering (Yandex Go Infra Meetup #2, запись опубликована в мае 2024). Смотрел запись. Двадцать минут, и редкий случай, когда кроме инструмента показывают, что учения нашли: жёсткие зависимости от «некритичных» сервисов и несогласованные таймауты. Про рубильники и про то, почему не взяли готовый инструмент, рассказано в ответах на вопросы, их стоит досмотреть.
Дмитрий Баскаков — Сломать, чтобы починить: парадокс хаос-инжиниринга в действии (Yandex Scale 2024). Смотрел. Начало — обзор инструментов и сравнение Chaos Mesh с Litmus, дальше практика Mindbox: эксперименты в проде каждый день, выбор времени запуска и истории о том, как эксперимент вышел из-под контроля. Ради второй части его и советую.
Lexiang Huang et al. — Metastable Failures in the Wild (OSDI ’22). Продолжение работы Bronson с разбором реальных сбоев. Для этого листа советую случай с пиковым нагрузочным тестом в Twitter: зрелый сервис не восстановился после снятия нагрузки, пока его не перезапустили. Лучшего довода проверять возврат к норме, а не только остановку, я не знаю.
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, нагрузка на ресурсы в локальных контейнерах. Лёгкий вариант для экспериментов на машине разработчика, хотя сам я до него не добрался.

Шаблоны

Сценарий Game Day — заготовка из этого репозитория для игры с инъекцией: гипотеза о нормальном состоянии записывается до старта, рядом стоят радиус поражения, условия остановки и уборка. Для непрерывных автоматических экспериментов она не предназначена.

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 сразу в проде — это просто инцидент. После него команда теряет доверие к практике, и вернуть его дороже, чем было бы подождать один квартал. Время запуска в проде тоже выбирают. Дмитрий Баскаков из Mindbox на Yandex Scale 2024 советует не пик и не часы, когда трафика почти нет, а середину нагрузки, лучше на спаде: если что-то пошло не так, задетых пользователей становится меньше само собой. Для меня сюда же относится рабочий день: неприятный сюрприз во вторник днём дешевле, чем в субботу в три ночи.

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

У автоматической остановки есть слабое место: она снимает инъекцию, но не проверяет, что эксперимент закончился. Самый наглядный пример, который я знаю, из того же доклада Баскакова. Команда проверяла плавную деградацию: изолировала по сети один сервис и смотрела, переживёт ли это соседний, который от него зависит. Соседний пережил, и все разошлись. На следующий день он в случайный момент начал отвечать пятисотыми, и инженер минут двадцать искал причину: алертов по инфраструктуре нет, в канале уведомлений о хаосе пусто. Оказалось, сетевая изоляция так и не снялась, а сервис всё это время жил на кеше, пока тот не протух. С тех пор алерты на инфраструктуру, которую ломает эксперимент, там не глушат, пока сценарий не прошёл успешно пару раз. В том же докладе есть история короче и страшнее: эксперимент изолировал сервис вместе с самой хаос-платформой, и контроль над экспериментами пропал. Команда «закончить» идёт к цели тем же путём, что и «начать», и если эксперимент этот путь перерезал, остановки нет.

Бывает и хуже. Снятая инъекция ничего не возвращает, потому что система вошла в метастабильный отказ и держит себя в нём сама. Механика разобрана в Resilience Patterns, здесь важно другое: войти в такой отказ можно и на проверке. В статье Metastable Failures in the Wild (OSDI ’22) описан пиковый нагрузочный тест в Twitter. Сервис зрелый, годами живёт с частыми выкладками, регулярными стресс-тестами и мониторингом. На тесте доля успешных ответов поползла вниз, нагрузку несколько раз сбрасывали, она вернулась к уровню до теста, а доля успешных всё падала. Ниже SLO она оставалась, пока операторы не перезапустили сервис. Мой вывод для экспериментов с нагрузкой и задержкой: гипотеза пишется с хвостом. К «во время инъекции SLI в пределах Z» добавляется «после снятия система сама вернётся к норме за N минут». Bronson с соавторами тем же приёмом предлагают мерить запас до метастабильного отказа: дать нагрузку, подать триггер и смотреть, успокоится ли система без вмешательства. Раз хвост может не сбыться, в плане заранее записан выход: чем сбросить нагрузку и как выключить повторы. И масштаб. По словам тех же авторов, сила петли зависит от масштаба, поэтому тест на уменьшенной копии мало что гарантирует для полной системы. В Яндекс Такси то же сказали проще: ошибки от большого числа запросов на себе и в тестинге не находятся.

Сам инструмент хаоса тоже часть прода, и спрос с него строже, чем с сервисов, которые он проверяет. В Яндекс Такси рассказывали, как раскатывали инъекцию на восемьсот микросервисов. Обычный цикл обновления всех сервисов там занимает год или два, поэтому плагин к Nginx на Lua добавили одной строкой в кодогенерацию, и он приезжает в каждый сервис с очередной выкаткой. Правило для плагина жёсткое: он никогда не блокирует сервис, особенно когда хаос выключен. Конфигурацию читает асинхронно, любую свою ошибку проглатывает, и запрос идёт дальше. Не включился хаос — не страшно. Включение ограничено так же строго. Дольше заданного времени, в среднем пяти минут, хаос не работает. Рубильников четыре, и друг от друга они не зависят. Выключение занимает секунды, а аудиторию выбирают явно, чаще всего это свои сотрудники. Прямо на докладе хаос включили участникам митапа: цены в приложении не грузились, но машину заказать было можно, поездку считали по таксометру.

Главное, что находят такие учения, — критичность, которую никто не записывал. В Такси критичными считают сервисы, без которых не уехать: выбор исполнителя, хранилище текущих заказов. Остальные восемьсот, вроде промокодов и отправки чеков, подождут. Учения нашли два «некритичных» сервиса, зависимость от которых оказалась жёсткой: без них складывалось всё такси. И три места, где не сходились таймауты. На входящий запрос отведено 1 000 мс, вложенному вызову в конфигурации разрешено 2 000, и проброс дедлайна на таком пути не работает. Это ровно оговорка из Resilience Patterns: разметка критичности остаётся гипотезой, пока зависимость не отключили. Тем же приёмом отвечают и на другой вопрос, какие вызовы входят в SLI: в Mercari по очереди заставляли API отвечать ошибкой 500 и проходили пользовательский путь заново; подробно это разобрано в SLO Engineering. Из доклада Такси стоит взять ещё две детали. Охват: критичные сервисы и первый круг тех, в кого они ходят, а что дальше, пока не трогают. И место задержки: её вставляют после похода в зависимости, иначе запрос не успевает разойтись по цепочке, и эксперимент проверяет один сервис вместо системы.

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’ом.