В этом посте затронем тему про Chaos Engineering и роль мониторинга в обеспечении отказоустойчивости сложных ИТ-систем. Возможно, вы уже слышали про термин хаос-инжиниринг, и если ваша ИТ-инфраструктура обслуживает критически важные сервисы с большим числом пользователей, то самое время добавить ей надежности, внедрив этот самый Chaos Engineering вместе с системой зонтичного мониторинга. 

Введение

Chaos Engineering (хаос-инжиниринг) — это подход к повышению надежности и отказоустойчивости сложных распределенных систем путем проведения контролируемых экспериментов, которые моделируют реальные сбои. Основная идея заключается в том, чтобы искусственно создавать стрессовые условия в системе и наблюдать за ее поведением. Метод позволяет заранее обнаружить уязвимости, которые могут остаться скрытыми до возникновения настоящих инцидентов.

Считается, что термин Chaos Engineering впервые появился в Netflix в начале 2010-х годов. Это было время быстрого роста бизнеса и компания столкнулась с необходимостью гарантировать стабильность своей системы потокового вещания, обслуживающей миллионы пользователей одновременно. Идею предложили инженеры Netflix, Грег Орсиро (Greg Orzell) и другие участники команды Site Reliability Engineering (SRE). Они разрабатывали способы протестировать устойчивость системы в условиях реальных сбоев.

Для этой цели инженеры Netflix создали инструмент Chaos Monkey, который искусственно отключал случайные сервисы в производственной среде. Это позволило понять, как такие сбои влияют на общую работоспособность системы, и подготовиться к подобным ситуациям. Дошло до того, что тестирование, названное Chaos Kong, проходило даже на продакшн-серверах, которые произвольно отключали из облака AWS.

Со временем термин хаос-инжиниринг стал обозначать целую практику (см. https://principlesofchaos.org/ru/), вышел за рамки принадлежности только к Netflix и стал применяться в разных отраслях ИТ.

Концепция Chaos Engineering

Цель хаос-инжиниринга — создать в вашей корпоративной системе условия, близкие к реальным сбоям, чтобы по максимуму выявить потенциально слабые места в отказоустойчивости. Разумеется, итогом этой работы должны стать выявленные недостатки и разработанные методы восстановления.

Концепция Chaos Engineering основывается на предположении, что любые сложные распределенные системы имеют потенциальные уязвимости, которые остаются скрытыми до тех пор, пока «что‑то пойдет не так». Эти уязвимости могут возникнуть из-за множества причин, среди наиболее частых  — сложное взаимодействие множества сервисов, частые апдейты и патчи в рамках CI/CD, сбои сети и иные отказы «железа», отказы со стороны сторонних поставщиков услуг.

Зачем современным системам нужна подготовка к сбоям

Современные приложения зачастую построены на основе сложной, распределенной архитектуры (микросервисы, контейнеры, Kubernetes). Такие системы работают в условиях постоянно меняющихся нагрузок и зависят от множества компонентов: сетей, баз данных, сторонних API и других сервисов.

Возникший сбой в одном из компонентов может привести к цепной реакции, которая затронет пользователей и бизнес-процессы. В последние годы СТО и другие руководители компаний среднего и крупного бизнеса в России и других странах перестали воспринимать Chaos Engineering как некую избыточную практику, которая подходит лишь для уровня мультинациональных корпораций (хотя и у них такие сбои случаются, и даже у самого Гугла).

СТО теперь четче осознают причины, почему практика хаос-инжиниринга как подготовки к сбоям стала необходимостью и когда рекомендуется ее внедрять:

• Если у вас требования к доступности 99,99% и выше.

• Если значительно выросла и продолжает расти сложность архитектуры, что увеличивает вероятность непредвиденных отказов.

• Если релизная политика предполагает частые обновления, что увеличивает вероятность появления несовместимости ПО и ошибок в работе сервисов.

Далее давайте пройдемся по основным принципам Chaos Engineering. Здесь есть свои “3 кита”:

1. Строится гипотеза о нормальной работе системы. Перед проведением эксперимента определяется, как система должна вести себя в штатных условиях.

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

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

В заключение раздела — пара примеров из открытых источников, где Chaos Engineering совершенно точно помог бы предотвратить значительные убытки компаниям и неудобства для клиентов.   

1. Сбой в авиасистеме British Airways в 2017 году
   Проблема с электросетью привела к отказу ключевой системы управления рейсами. Эксперимент, который отключил бы сеть в тестовой среде, мог показать, что автоматическое переключение сервисов между дата-центрами работает некорректно.
   Подробнее об инциденте …

2. Outage в Google Cloud (2013 - 2022)
   За последние 12 лет зафиксировано 8 серьезных инцидентов с доступностью Google Cloud. В частности, в 2020 году отказ в балансировщике нагрузки привел к недоступности ряда сервисов. Хаос-эксперимент с отключением балансировщика и нагрузочным тестированием мог бы помочь обнаружить проблемы в алгоритме переключения нагрузки.
   Подробнее об этих инцидентах …

Общая методика построения экспериментов хаос-инжиниринга

1. Постановка цели эксперимента

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

• Проверить, сохраняется ли доступность веб-приложения при отказе одного из узлов базы данных.

• Определить, как система восстанавливается после отключения и переподключения сети между микросервисами.

Этот список — только примеры, в вашей конкретной организации рекомендуется тестировать поведение системы при воздействии на известные “болевые точки”, SLA/SLO вашего сервиса и бизнес-риски, чтобы сформулировать приоритетные задачи хаос-экспериментов.

2. Анализ архитектуры и выбор области тестирования

После того, как цель эксперимента определена, проводится анализ архитектуры системы, чтобы выявить ее ключевые зависимости:

• Какая часть системы наиболее уязвима при сбое выбранного сервиса?

• Какие компоненты критически важны для бизнес-функций?

Ответив на эти вопросы, затем выберите область для экспериментов — например, отдельный микросервис, кластер базы данных или подсистему балансировки нагрузки.

3. Построение гипотезы поведения системы

Для проведения эксперимента нужна гипотеза, которая описывает ожидаемое поведение системы. Пример:
«Если один из серверов базы данных станет недоступен, запросы должны перенаправляться на резервные узлы без увеличения времени отклика более чем на 10%». Вот это и проверяйте в эксперименте.

По возможности оперируйте числовыми параметрами, а не просто “хорошо” или “плохо”. Гипотеза с конкретными показателями позволит определить критерии успеха или неудачи.

4. Планирование сценариев отказов

Определите, какие сбои и где вы будете вводить в систему:

• Отключение узла — например, отключение одного сервера или микросервиса из системы.

• Потеря связности — эмуляция сетевых проблем (долгий ping, большой % потери пакетов).

• Снижение производительности — искусственное увеличение нагрузки на процессоры, СХД и адаптеры ввода-вывода.

• Ошибка приложения — запуск сбойного кода, который вызывает исключение или краш сервиса.

Каждый сценарий должен быть продуман в безопасных пределах, чтобы не нанести ущерб остальной системе.

5. Выбор инструментов хаос-инжиниринга

Готовые инструменты хаос-инжиниринга помогают автоматизировать создание сбоев. Вот примеры популярных инструментов, которые позволяют задавать точные параметры отказов и собирать данные о состоянии системы:

• Gremlin или аналоги для создания различных сценариев, включая сетевые сбои, падение сервисов и изменения нагрузки.

• Litmus Chaos или аналоги в качестве платформы для тестирования Kubernetes.

6. Проведение первого эксперимента в изолированной среде

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

7. Сбор данных и наблюдение за системой

Мониторинг поможет зафиксировать:

• Время отклика системы до, во время и после эксперимента.

• Доступность ключевых компонентов.

• Отклонения метрик, логов и трейсов.

8. Масштабирование хаос-экспериментов на всю ИТ-систему

По мере набора опыта в хаос-инжиниринге, команды DevOps/AIOps и техподдержки могут переходить к более масштабным экспериментам. К примеру, смоделировать реакцию систем на пиковые нагрузки от пользователей, кибератаки на ИТ-инфраструктуру, отключение внешних сервисов сторонних провайдеров, отключение электричества в масштабе города и региона и т.д. Конкретный выбор, куда масштабировать хаос-эксперименты зависит от области деятельности компании и многих других факторов.

Как определить, какие сбои вводить в систему

1. Базируйтесь на прошлых сбоях, чтобы тестировать на них основе похожие сценарии.

2. Тестируйте поведение ключевых зависимостей (базы данных, сети, балансировщики).

3. Проверяйте бизнес-риски: выявляйте, где отказ будет наиболее критичен для пользователей (например, сбой каких модулей в онлайн-магазине полностью остановят торговлю).

4. Проверяйте соответствие критическим SLA/SLO, т.е. тестируйте элементы, напрямую влияющие на выполнение соглашений по уровню обслуживания.

5. Проверяйте трендовые угрозы — пробуйте эмулировать инциденты, которые произошли в схожих системах ваших конкурентов или в отрасли в целом.

Этот методический подход гарантирует, что эксперименты будут безопасными, управляемыми и направленными на максимальное улучшение отказоустойчивости вашей системы.

Роль мониторинга в обеспечении отказоустойчивости

Мониторинг — это основа, без которой хаос-инжиниринг будет пустой тратой времени и ресурсов команды DevOps. Его задачи в контексте этой практики можно описать так:

1. Наблюдение за поведением системы во время экспериментов чтобы анализировать метрики (загрузка сети, процессоров и других “железячных” компонентов, время ответа, потребление памяти и т.д., логи (ошибки, исключения) и трейсы.

2. Ранняя диагностика последствий вмешательств — система мониторинга фиксирует отклонения от нормы в режиме реального времени и сигнализирует о критических изменениях. Основываясь на визуализации поведения ИТ-системы в платформе мониторинга, команда DevOps может принимать более уверенные решения о продолжении или приостановке эксперимента.

3. Документирование результатов: отчеты постмортем помогут четче понять влияние сбоев на систему и наполнить базу знаний собственными методиками восстановления для предотвращения проблем в будущем.

4. Поддержка быстрого восстановления: мониторинг выявляет узкие места и упрощает процесс поиска источника проблем, предоставляя материал для обновления должностных инструкций и корпоративных методик восстановления.

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

Интеграция мониторинга в хаос-инжиниринг

Для успешной интеграции мониторинга в хаос-инжиниринг команде DevOps рекомендуется инсталлировать (зонтичную) систему мониторинга, которая не только отображает текущие показатели состояния инфраструктуры, но и активно используется для анализа поведения системы во время и после экспериментов. Такая система должна собирать метрики производительности, анализировать трассировки распределенных систем и фиксировать ошибки, чтобы в реальном времени оценивать влияние сбоев.

Обычные системы мониторинга способны отображать состояние инфраструктурных компонентов, таких как серверы, базы данных и сети. Однако они не связывают эти показатели с реальной работоспособностью бизнес-сервисов. Только мониторинг бизнес-сервисов, который связывает инфраструктурные метрики с ключевыми процессами, позволяет понять, как сбои влияют на пользователя и восстановление бизнес-операций. Например, если из-за отказа системы хранения данных (СХД) отключились пять бизнес-сервисов, система мониторинга должна показать факт и временную отметку их недоступности и процесс восстановления после переключения на резервное оборудование.

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

В первую очередь необходимо определить ключевые метрики (CPU, память, время отклика, количество отказов и доступность), логи и трассировки, которые будут играть основную роль в оценке устойчивости корпоративной ИТ-инфраструктуры. Эти данные должны быть агрегированы в системе мониторинга и представлены в виде дашбордов, что позволит команде в реальном времени видеть влияние проводимых экспериментов на устойчивость ИТ-инфраструктуры и вовремя прекратить эксперимент, если он принял разрушительный характер для сервисов и бизнес-процессов.

После определения набора ключевых метрик дальнейшим шагом для команды DevOps будет настройка алертов и пределов нормальных значений метрик. Это необходимо, чтобы на ранней стадии обнаружить неконтролируемые последствия экспериментов. Дополнительно, DevOps-инженеры должны создать план действий на случай, если тест приведет к реальной деградации системы: настройки для автоматического восстановления компонентов, процедуры ручного вмешательства и сценарии отката изменений. 

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

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

1. Метрики производительности:

   • Время отклика сервиса отражает, как сбои влияют на задержки в системе.

   • Загрузка процессоров и памяти показывает, как ведут себя эти ресурсы при сбое.

2. Логи ошибок:

   • Коды ошибок, такие как 500 (серверные ошибки) могут сигнализировать о перегрузке оборудования.

   • Текстовые сообщения в логах дают информацию о деталях сбоя, причинах и последовательности событий.

3. Трейсы распределенных систем:

   • Связь между компонентами. Позволяют визуализировать, какие сервисы пострадали больше всего и где началась цепная реакция отказов.

   • Продолжительность запросов. Помогают найти излишне медленные узлы в системе.

Автоматизация сбора и анализа данных с Monq

Когда метрики хаос-эксперимента определены, рекомендуется автоматизировать их сбор и обработку, включая:

1. Сбор метрик и логов в Monq поддерживается интеграцией с различными источниками данных (базы данных, контейнеры, API). Это позволяет собирать всю информацию в одном месте.

2. Визуализация данных через графики, дашборды и алерты помогает оперативно оценивать состояние системы.

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

4. Постэкспериментальные отчеты и аналитика (постмортем): Monq может собирать полные отчеты о проведенных экспериментах с указанием аномалий и предложений по их устранению.

Пример тестирования отказоустойчивости ЦОД с помощью хаос-инжиниринга и Monq

Крупный центр обработки данных (ЦОД), с которым мы связаны соглашением по NDA, проводил регулярные эксперименты хаос-инжиниринга для повышения отказоустойчивости своей инфраструктуры. Основной целью было проверить, как система справляется с внезапными сбоями, а также выявить слабые места, которые могут повлиять на доступность ключевых бизнес-сервисов. Monq используется в ЦОД как “зонтик”, для мониторинга бизнес-сервисов и метрик.

Цель эксперимента

Основная задача состояла в тестировании отказоустойчивости при потере одного из главных узлов системы распределения трафика (кластер балансировщиков нагрузки). Эксперимент должен был ответить на следующие вопросы:

• Сможет ли система автоматически перенаправить трафик на резервные узлы без значительной деградации производительности?

• Как быстро восстановится доступность бизнес-сервисов?

• Какие метрики и показатели покажут, что система функционирует в штатном режиме?

Проведение эксперимента

1. Подготовка

Monq уже давно задействован в ИТ мониторинге этого ЦОД, поэтому на момент первого тестирования основные этапы подготовки уже были пройдены: 

• На стороне РСМ (ресурсно-сервисной модели)  была собрана карта зависимостей бизнес-сервисов (более 500), инфраструктурных и сетевых компонентов.

• Были определены ключевые метрики: время отклика сервисов, нагрузка на оставшиеся узлы балансировщиков, время переключения на резервные компоненты.

• Настроены алерты в Monq для быстрого уведомления команды об отклонениях метрик от нормы.

2. Сценарий отказа

• Один из балансировщиков нагрузки в кластерной группе был отключен искусственно.

• Сценарий тестирования был заранее согласован: сбой вводился в не пиковое время с предусмотренными шагами отката.

3. Наблюдение

• Граф РСМ начал фиксировать влияние сбоя в реальном времени. На карте здоровья  сразу стали видны следующие показатели:

  • Рост времени отклика на 25% у части бизнес-сервисов.

  • Увеличение нагрузки на оставшиеся узлы балансировщиков до 85% (при норме 70%).

  • Логи показали, что некоторые соединения с резервными балансировщиками заняли на 15 секунд больше времени, чем планировалось.

4. Выводы

• Monq помог быстро определить «узкое место» — один из резервных балансировщиков не был готов к приему трафика из-за некорректной конфигурации маршрутов.

• Система также подсветила потенциальный риск: один из сервисов, критичных для бизнеса, не был связан с резервным балансировщиком, что могло привести к его полной недоступности при более серьезном сбое.

Результаты и улучшения

После анализа собранных метрик и логов:

• Были обновлены конфигурации маршрутов, чтобы резервные балансировщики могли принимать трафик без задержек.

• На основе анализа данных о нагрузке были установлены более низкие пороговые значения для алертов, чтобы предупреждать команды об увеличении нагрузки заранее.

• Команда провела дополнительное тестирование связей бизнес-сервисов с резервными компонентами, чтобы гарантировать их доступность при любых отказах.

Эксперимент доказал, что хаос-инжиниринг в сочетании с мониторингом позволяет не только выявлять критические уязвимости, но и предотвращать будущие инциденты.

Заключение

Системы мониторинга делают процесс Chaos Engineering более управляемым и безопасным, снижая риски негативного воздействия на сервисы и инфраструктуру в процессе тестирования. Используя возможности сценариев и автоматизации, Monq позволяет минимизировать ручной труд инженеров DevOps, повысить эффективность мониторинга в процессе хаос-экспериментов.

Приглашаем специалистов оптимизировать мониторинг ИТ-инфраструктуры и управление инцидентами с платформой Monq.

Описанные в статье кейсы можно реализовать на комьюнити версии Monq.

Также приглашаем присоединиться к программе раннего доступа и протестируйте бесплатный облачный сервис Monq On-Call.