9.6 Хаос-инженерия и тестирование устойчивости

Обзор и мотивация

Хаос-инженерия это дисциплинированная практика проведения экспериментов над системой, чтобы построить уверенность в её способности выдерживать турбулентные условия в производстве. Название звучит безрассудно, и это первое, от чего нужно отучиться. Хаос-инженерия не ломание всего подряд в надежде чему-то научиться. Это противоположность: контролируемый, управляемый гипотезами метод внесения реалистичных отказов, чтобы вы обнаружили слабости раньше ваших пользователей. Вы уже знаете, что ваша система столкнётся с отказами, потому что так бывает у каждой реальной системы. Единственный вопрос в том, встретите ли вы эти отказы во вторник днём с готовым откатом или в три часа ночи в самый загруженный час, не понимая, что происходит.

Для больших команд это важно, потому что сложность переросла способность кого бы то ни было рассуждать о ней осмотром. Современный сервис это сеть из десятков или сотен компонентов, у каждого свои тайм-ауты, повторы, кэши и режимы отказов, а взаимодействия между ними производят возникающее поведение, которого не предсказывает ни одна архитектурная схема. Можно рецензировать код, рисовать блоки и всё равно оказаться застигнутым врасплох, когда медленная зависимость запускает шторм повторов, обрушивающий сервис тремя переходами дальше. Хаос-инженерия то, как вы эмпирически исследуете эти взаимодействия, чтобы ваша устойчивость была проверена, а не предполагалась.

Корпоративный и государственный контексты повышают ставки и, всё чаще, мандат. Финансовые регуляторы теперь ожидают, что фирмы проверяют операционную устойчивость против суровых, но правдоподобных сценариев и доказывают, что могут поддерживать критичные услуги в работе через сбой. Государственные органы проводят учения по непрерывности операций, чтобы основные общественные услуги переживали сбои, катастрофы и кибератаки. В обоих мирах «мы думаем, что выдержит» неприемлемый ответ аудитору или гражданину. Хаос-инженерия даёт свидетельства. Эта глава опирается на инженерию надёжности сайтов (глава 9.1) и шаблоны устойчивости главы 3.5 и тесно связана с управлением инцидентами (глава 9.3) и аварийным восстановлением (глава 9.5).

Ключевые принципы

Стройте уверенность, не создавайте хаос. Цель проверенная устойчивость, а не зрелище. Каждый эксперимент отвечает на конкретный вопрос о том, как система ведёт себя под нагрузкой.
Сначала определите устойчивое состояние. Нельзя обнаружить проблему без ясного, измеримого определения того, как выглядит «здоровое».
Сформулируйте гипотезу. Скажите, чего вы ожидаете, прежде чем внести отказ. Сюрприз это находка; отсутствие сюрприза тоже находка.
Минимизируйте и сдерживайте радиус поражения. Начинайте с малого, защищайте реальных пользователей и расширяйте объём лишь по мере роста уверенности.
Предпочитайте производство, осторожно. Отказы ведут себя иначе под реальным трафиком, реальными данными и реальным масштабом. Заслужите право тестировать там.
Автоматизируйте в сторону непрерывной проверки. Слабость, исправленную раз, можно вернуть регрессией. Устойчивость, тестируемая непрерывно, остаётся истинной.
Отказ учитель, а не приговор. Находки улучшают систему; они никогда не повод обвинять человека, проводившего эксперимент.

Рекомендации

Установите предпосылки, прежде чем внести хоть один отказ

Хаос-инженерия множитель силы для зрелой системы и обязательство для незрелой. Прежде чем начинать, нужно иметь на месте три вещи. Первое, наблюдаемость, то есть метрики, журналы и трассировки, позволяющие видеть снаружи, что делает ваша система, потому что эксперимент, который вы не можете наблюдать, ничему не учит. Второе, цели уровня обслуживания или эквивалентное определение здоровья в устойчивом состоянии (глава 9.1), чтобы в реальном времени отличать успешный эксперимент от вредного. Третье, быстрый и заслуживающий доверия путь отката или прерывания, чтобы в момент, когда эксперимент угрожает реальным пользователям, вы могли остановить его и восстановить нормальное обслуживание за секунды. Если вы не можете измерить систему, определить её здоровое состояние и вернуть её с края, не запускайте хаос-эксперименты пока. Сначала постройте эти возможности. Они окупаются в любом случае.

Определите устойчивое состояние и сформулируйте настоящую гипотезу

Каждый эксперимент начинается с записи того, как выглядит норма, в измеримых терминах: доля успешных запросов выше 99,9 процента, задержка оформления заказа менее 400 миллисекунд на 95-м процентиле, глубина очереди ниже порога. Это ваше определение устойчивого состояния, и оно должно отражать видимое пользователю здоровье, а не внутреннюю сантехнику. Затем сформулируйте гипотезу простым языком: «Если мы добавим 300 миллисекунд задержки сервису рекомендаций, страница продукта всё равно отрисуется в пределах бюджета задержки, потому что страница воспринимает рекомендации как необязательные и обрывает ожидание через 200 миллисекунд». Теперь у вас опровержимое утверждение. Когда вы запускаете эксперимент, происходит одно из двух хороших событий. Либо система ведёт себя, как предсказано, и ваша уверенность заслужена, либо нет, и вы нашли настоящую слабость дёшево, на своих условиях, при наблюдающих инженерах.

Вносите реалистичные отказы, а не произвольные

Отказы, которые вы вносите, должны отражать отказы, которые ваша система действительно переживает. Внесение отказов, намеренное введение ошибок для проверки реакции системы, даёт вам меню, взятое из настоящих производственных инцидентов. Вносите задержку, чтобы имитировать медленную зависимость или насыщенное сетевое соединение. Вносите ошибки, возвращая HTTP 500 или отказы соединения, чтобы имитировать отказывающий нижестоящий сервис. Вносите исчерпание ресурсов, потребляя процессор, память, диск или дескрипторы файлов, чтобы увидеть, как система деградирует под давлением. Вносите отказ зависимости, делая целую базу данных, кэш, очередь или сторонний API недоступными. В распределённой системе, где компоненты работают на отдельных машинах и общаются по ненадёжной сети, именно эти отказы доминируют в реальных сбоях. Задержка и частичный отказ, а не чистые падения, ломают вещи на практике, поэтому смещайте эксперименты в сторону грязной середины.

Проверяйте, что ваши механизмы устойчивости действительно работают

Здесь хаос-инженерия отрабатывает своё содержание. Ваша система полна механизмов, призванных вас защищать: тайм-ауты, не дающие вызывающему ждать вечно, повторы, замазывающие кратковременные сбои, предохранители, прекращающие долбить отказывающую зависимость, и переключение на резерв, переходящее на резерв, когда основной умирает. Эти шаблоны, рассмотренные в главе 3.5, разница между сдержанной проблемой и каскадным сбоем. Беда в том, что их редко тестируют в условиях, для которых они существуют. Тайм-аут в 30 секунд, когда собственный срок вызывающего 2 секунды, ничего не делает. Повтор без отсрочки превращает один затрудняющийся сервис в стадо, бросающееся грудью. Предохранитель, который никогда не задействовали, может быть неверно настроен и никогда не срабатывать или срабатывать постоянно. Хаос-эксперименты то, как вы подтверждаете, что каждый из них ведёт себя как задумано, когда отказ, от которого он защищает, действительно приходит. Предполагайте, что каждый непроверенный механизм безопасности сломан, пока эксперимент не докажет обратное.

Начинайте с игровых дней, прежде чем автоматизировать

Не начинайте с автоматизированной платформы, непрерывно вносящей отказы. Начните с игрового дня: запланированного практического упражнения, где команда собирается, выбирает сценарий, вносит отказ в контролируемой среде и наблюдает вместе. Ещё раньше настольное упражнение, где вы проговариваете сценарий у доски, не касаясь системы, выявляет пробелы в ранбуках, оповещении и владении почти без риска. Игровые дни ваш въезд. Они развивают мышцу формулирования гипотез, сдерживания радиуса поражения и чтения системы под нагрузкой и строят доверие с руководством и соседними командами, которое понадобится до того, как вам кто-либо позволит проводить эксперименты в производстве. Они также напрямую укрепляют реагирование на инциденты, потому что навыки те же, что используют ваши дежурные инженеры во время настоящего инцидента (глава 9.3). Проводите первые игровые дни в промежуточной среде, затем в производстве в тихие часы с малым радиусом поражения, затем расширяйте.

Сдерживайте радиус поражения намеренно

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

Двигайтесь к непрерывной автоматизированной проверке устойчивости

Случайные игровые дни находят слабости, но системы меняются каждый день, а исправление прошлого квартала может тихо вернуться регрессией. Зрелое конечное состояние непрерывная проверка: курируемый набор экспериментов устойчивости, работающих автоматически, в конвейере или по расписанию, так что регрессия в тайм-ауте, политике повторов или пути переключения ловится в течение дней, а не во время следующего настоящего сбоя. Именно здесь инструменты вроде Chaos Monkey от Netflix, случайно завершающего экземпляры в производстве, чтобы заставить инженеров строить сервисы, терпимые к потере экземпляров, заслужили репутацию. Автоматизируйте только эксперименты, которые вы уже понимаете и которым доверяете по ручным запускам. Непрерывный хаос поверх незрелой системы способ порождать инциденты, а не уверенность.

Связывайте эксперименты с аварийным восстановлением и обучением на инцидентах

Хаос-инженерия живёт не в одиночестве. Более крупные, более редкие сценарии, потеря целого региона, переключение базы данных, восстановление из резервной копии, относятся к тестированию аварийного восстановления (глава 9.5), а игровой день нередко лучший способ отработать эти планы, вместо того чтобы дать им гнить как непроверенным документам. С другой стороны, каждый эксперимент, выявивший слабость, должен питать тот же цикл обучения, что и настоящий инцидент (глава 9.3): разбор без обвинений, отслеживаемое исправление и повторный эксперимент, подтверждающий, что исправление держится. Когда находки хаоса, учения по аварийному восстановлению и ретроспективы инцидентов текут в одну очередь работы над устойчивостью, вы получаете накапливающуюся отдачу вместо разбросанных разовых упражнений.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Тестирование в производстве	Реальный трафик, данные и масштаб; находки истинны	Риск для пользователей при провале сдерживания; нужна зрелость
Тестирование только в промежуточной среде	Безопасно, низкие ставки, легко начать	Пропускает реальное поведение; ложная уверенность
Ручные игровые дни	Строят навыки и доверие; низкая цена инструментов	Редко; находки могут вернуться регрессией незаметно
Непрерывный автоматизированный хаос	Быстро ловит регрессии; масштабируется	Сначала нужны зрелые инструменты и наблюдаемость
Широкий радиус поражения	Выявляет крупные системные слабости	Высокий риск; ошибка становится инцидентом
Узкий радиус поражения	Безопасно и контролируемо	Может пропускать возникающие межсервисные отказы

Центральное напряжение между реализмом и безопасностью. Находки, которые вы хотите больше всего, приходят из производства, потому что только там ваша система сталкивается с реальным трафиком, реальными данными и реальным масштабом, однако производство как раз то место, где испорченный эксперимент вредит пользователям. Разрешение не в выборе одной стороны. Оно в постепенном заслуживании пути к производству: докажите предпосылки, отрепетируйте в промежуточной среде, затем запускайте малые, хорошо сдерживаемые эксперименты в производстве с условиями прерывания, привязанными к живым метрикам, и расширяйте объём лишь по мере накопления свидетельств. Другое повторяющееся напряжение, ручное против автоматизированного, разрешается так же со временем. Начинайте вручную, чтобы построить понимание и доверие, затем автоматизируйте эксперименты, на которые вы стали полагаться, чтобы устойчивость, проверенная раз, оставалась проверенной.

Вопросы для обсуждения с командой

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

Взгляд по секторам

Стартап. Скорость и выживание доминируют, поэтому не тратьте ничего на платформу хаоса. Проведите один девяностоминутный игровой день в промежуточной среде против единственной зависимости, чей отказ вас действительно убил бы, обычно платежи, аутентификация или основное хранилище данных. Внесите отказ грубым прокси или убитым процессом, посмотрите, что ломается, исправьте недостающий тайм-аут или запасной вариант и идите дальше. Весь смысл в дешёвой ловле очевидного самонанесённого сбоя раньше клиента, а не в построении дисциплины, которую вы не можете укомплектовать.

Малый бизнес. Без специалиста по надёжности и при ограниченном бюджете воспринимайте тестирование устойчивости как периодическое намеренное упражнение, а не программу, которую вы комплектуете персоналом. Опирайтесь на возможности внесения отказов, уже включённые в вашего облачного провайдера или управляемые инструменты, вместо покупки выделенной платформы, и сосредоточьте эксперименты на горстке зависимостей, которые заметил бы клиент. Формулируйте это как страховку: день, потраченный на подтверждение, что ваши резервные копии восстанавливаются, а оформление заказа изящно деградирует, гораздо дешевле сбоя, доказывающего обратное.

Крупная организация. Проблема координация многих команд против общих зависимостей в масштабе, поэтому стандартизируйте планку готовности, политику радиуса поражения и привязку условий прерывания, которые должна пройти каждая команда до запуска в производстве. Направляйте находки хаоса, учения по аварийному восстановлению и ретроспективы инцидентов в одну очередь устойчивости с ясным владением и используйте ежеквартальные игровые дни плюс курируемый набор автоматических экспериментов, чтобы удовлетворять ожиданиям операционной устойчивости свидетельствами. Управляйте тем, кому позволено затрагивать общий сервис, чтобы эксперимент одной команды не обрушил инфраструктуру, от которой зависят другие.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность формируют работу. Мандаты непрерывности операций нередко и так требуют регулярных учений, поэтому проводите их как живые игровые дни, дающие настоящие находки, а не папку, которую никто не открывает, и ведите след аудита каждого эксперимента, его радиуса поражения и исхода. Где закупаются инструменты внесения отказов, требуйте, чтобы они укладывались в правила безопасности и обращения с данными, и оставляйте производственные эксперименты над сервисами для граждан для туго сдерживаемых утверждённых окон. Свидетельства, которые производит программа хаоса, именно то, что ожидает увидеть надзорный орган или аудитор.

Примеры

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

Крупная организация. Глобальный банк должен продемонстрировать регуляторам операционную устойчивость против суровых, но правдоподобных сценариев. Его команда надёжности ведёт программу ежеквартальных игровых дней плюс набор автоматических экспериментов в производстве. Один сценарий переключает основную базу данных транзакций на резерв в окно малого трафика со строго сдержанным радиусом поражения и условиями прерывания, привязанными к доле успешных транзакций. Первый запуск показывает, что нижестоящий сервис сверки имеет политику повторов без отсрочки, производящую всплеск нагрузки, задерживающий восстановление далеко за цель времени восстановления в плане аварийного восстановления (глава 9.5). Находка идёт в ту же очередь, что и ретроспективы инцидентов, политика повторов исправляется экспоненциальной отсрочкой, а повторный эксперимент подтверждает, что переключение теперь завершается в пределах цели. Всё упражнение становится свидетельством для регулятора.

Государственный сектор. Национальное ведомство, ведущее портал пособий для граждан, обязано поддерживать непрерывность операций через сбои. Вместо того чтобы воспринимать план непрерывности как папку, которую никто не открывает, ведомство проводит ежегодное учение по непрерывности как живой игровой день. Команда имитирует потерю основного центра обработки данных и проходит переключение на вторичную площадку, отдельно внося задержку в зависимость проверки личности, чтобы увидеть, изящно ли портал деградирует. Они узнают, что непроверенный пробел мониторинга оставил дежурную команду слепой к замедлению сервиса идентификации, так что оповещения сработали поздно. Ведомство закрывает пробел наблюдаемости, обновляет ранбуки и планирует то же упражнение на следующий год, превращая требование соответствия в подлинную проверенную устойчивость для критичной общественной услуги.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от хаос-инженерии приходит от сбоев, которые никогда не происходят. Один крупный сбой большого сервиса может стоить от десятков тысяч до миллионов потерянной выручки, регуляторных штрафов, труда по устранению и репутационного ущерба, задерживающегося надолго после восстановления сервиса. Хаос-эксперименты превращают эти непредсказуемые дорогие сюрпризы в дешёвые плановые находки, которые вы исправляете по своему графику при наблюдающих инженерах и готовом откате. Нахождение сломанного тайм-аута во время контролируемого игрового дня стоит день. Нахождение его во время настоящего инцидента стоит сбоя, всеобщей суеты и доверия ваших пользователей. Арифметика в пользу игрового дня с большим отрывом.

Совокупная стоимость владения скромна, когда предпосылки есть, потому что хаос-инженерия повторно использует вложения в наблюдаемость, оповещение и откат, которые вам нужны так или иначе. Честные цены это инженерное время на проведение экспериментов, некоторые инструменты для внесения отказов и сдерживания радиуса поражения и культурная работа по приведению руководства в комфортное отношение к намеренному внесению отказа. Последнее настоящий барьер, и путь через него начинать в промежуточной среде, показывать находки, соответствующие деньгам или риску, и позволить нескольким сдержанным производственным экспериментам построить доверие. Чтобы обосновать перед руководством, формулируйте хаос-инженерию как измеримую страховку: представьте цену недавних инцидентов, покажите, какие из них поймал бы эксперимент устойчивости, и предложите программу, которая начинается с малого и расширяется лишь по мере доказательства. В регулируемых и государственных условиях добавьте угол соответствия, потому что тестирование операционной устойчивости и учения по непрерывности всё чаще ожидаются, а программа хаоса то, как вы удовлетворяете это ожидание свидетельствами, а не бумагами.

Антипаттерны и ловушки

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

Модель зрелости

Уровень 1, Начальный: Устойчивость предполагается, а не тестируется. Отказы обнаруживаются в производстве во время настоящих инцидентов. Нет ни игровых дней, ни внесения отказов, нередко и ясного определения того, как выглядит здоровое. Команда узнаёт о своих слабостях трудным путём, сбой за сбоем.
Уровень 2, Развитие: Команда проводит случайные игровые дни, обычно в промежуточной среде, с определённым сценарием и гипотезой. Устойчивое состояние определено для нескольких ключевых сервисов, и существует базовая наблюдаемость. Находки фиксируются, и некоторые исправляются, но практика непоследовательна по командам и зависит от отдельных энтузиастов, а не установленного метода.
Уровень 3, Стандартизация: Хаос-эксперименты документированная практика по организации с принуждаемыми политиками радиуса поражения, условиями прерывания и критериями готовности, которые сервис должен пройти до экспериментов в производстве. Эксперименты идут в производстве в контролируемых условиях, находки текут в общую очередь работы над устойчивостью рядом с ретроспективами инцидентов и учениями по аварийному восстановлению, а механизмы устойчивости проверяются, а не предполагаются. Каждая команда следует одному сценарию.
Уровень 4, Управление: Программа измеряется и контролируется данными относительно базовых значений. Вы отслеживаете покрытие устойчивости (какие критичные сервисы и какие механизмы, такие как тайм-ауты, повторы, предохранители и переключение, были проверены при настоящем внесённом отказе и как недавно), долю экспериментов, выявляющих находки, среднее время закрытия находки устойчивости и как часто ранее проверенный механизм регрессирует. Эти метрики рецензируются по фиксированному ритму, повышение в производство ограничивается свидетельствами, а не мнением, а эксперименты приоритизируются по измеренному риску ещё не проверенных механизмов.
Уровень 5, Оркестрация: Курируемый набор экспериментов работает непрерывно и автоматически, ловя регрессии в течение дней, а программа адаптируется по мере изменения системы и картины её рисков. Хаос-инженерия интегрирована по организации с конвейерами поставки, обучением на инцидентах и тестированием аварийного восстановления, так что новые сервисы по умолчанию наследуют проверку устойчивости. Устойчивость непрерывно проверяемое свойство системы, а руководство воспринимает программу как стандартное управление рисками, уточняемое по свидетельствам, а не особую инициативу.

Идеи для обсуждения

Как вы решаете, какой сервис в вашей организации первым заслуживает право проводить хаос-эксперименты в производстве и что должно быть верно, прежде чем это произойдёт?
Когда хаос-эксперимент выявляет серьёзную слабость, кто владеет исправлением и как не дать находке лежать нетронутой в очереди?
Где в вашем контексте линия между хаос-экспериментом, учением по аварийному восстановлению и игровым днём и имеет ли это различие значение для планирования?
Как бы вы убедили скептически настроенного руководителя, что намеренное внесение отказа в производство безопаснее статус-кво ожидания настоящих сбоев?
Каков наименьший, наиболее ценный первый эксперимент, который ваша команда могла бы провести в следующем месяце, и что помешало бы его провести?
Как тестирование устойчивости должно различаться между государственной услугой для граждан с мандатом непрерывности и внутренним корпоративным инструментом с малой базой пользователей?

Главные выводы

Хаос-инженерия это дисциплинированное, управляемое гипотезами экспериментирование для построения уверенности в устойчивости, а не случайное ломание.
Установите наблюдаемость, определение устойчивого состояния и быстрый откат, прежде чем вносить хоть один отказ.
Вносите реалистичные отказы (задержку, ошибки, исчерпание ресурсов, отказ зависимостей) и используйте их, чтобы проверить, что тайм-ауты, повторы, предохранители и переключение действительно работают.
Начинайте с настольных упражнений и игровых дней, сдерживайте радиус поражения намеренно и заслуживайте путь к производству и автоматизации.
Связывайте эксперименты с тестированием аварийного восстановления (глава 9.5) и обучением на инцидентах (глава 9.3), чтобы находки накапливались в единую очередь работы над устойчивостью.
Обращайтесь с находками без обвинений и исправляйте их; эксперимент, чей урок остаётся без внимания, хуже отсутствия эксперимента.

Источники и дополнительное чтение

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org