![](https://webcf.waybackmachine.org/web/20240223091149/https://habrastorage.org/getpro/habr/upload_files/89b/ae6/a92/89bae6a92c9b691e18af222b4bf6e8bc.png)
Продолжаем разбираться в построении процесса Chaos Engineering в Enterprise. Первую часть статьи можно прочитать здесь: Chaos Engineering Enterprise Version. Часть 1.
Вместо «Intro»
Прежде чем мы двинемся дальше, хотелось бы сразу затронуть вопрос: а где же сам Chaos Engineering? Где "hard core"? Где разборы кода или детализация bash-скриптов? Статья, похоже, написана для менеджеров.
Chaos Engineering - это больше, чем просто запуск экспериментов, это своеобразное отношение к разработке продуктов. Технически Chaos Engineering можно представить в виде 2-3 десятков скриптов (при желании можно разработать и более 50), которые будут выглядеть примерно так:
blade create network corrupt --percent 40 --destination-ip <IP> --interface <interface>;
Которые, в свою очередь, применяются к каждому элементу архитектуры автоматизированной системы (балансировщики, сервера приложений, шины и т.д.). В итоге мы получаем от 30 до 500 разнообразных сценариев на различные элементы системы.
Самое сложное начинается, когда возникают вопросы: кто проводит Chaos? Кому достанется, если будет найдена точка, в которой система неустойчива? А нужно ли измерять эффективность тех, кто проводит испытания? (Забегая вперед - не нужно. Там, где присутствует элемент творчества, введение KPI приведет к покраске заборов).
И так, двигаемся дальше...
4. Инициаторы практики Chaos Engineering и виды команд
Инициировать развитие практики в крупной корпорации возможно двумя путями: сверху и снизу.
Снизу - это когда в команде разработчиков появляется активный инженер, который недавно прочел материалы на Habr и теперь предлагает внедрить практику в текущий проект. Он вовлекает команду, настраивает необходимые инструменты и т.д.
Плюсы подхода:
Хорошо работает в компаниях с моно-продуктом или в инициативных группах.
Максимальная вовлеченность команды.
Найденные точки отказа продукта устраняются с высоким приоритетом.
Разработка быстро обучается и применяет паттерны отказоустойчивости.
Минусы подхода:
Плохо работает в крупных предприятиях с десятками/сотнями продуктов.
Не масштабируется с должным качеством.
Сверху - это когда практика продвигается при поддержке самого высокого руководства или при поддержке бизнеса, что происходит реже.
Плюсы подхода:
Хорошо работает в крупных предприятиях с десятками/сотнями продуктов.
Позволяет преодолеть бюрократию.
Хорошо масштабируется с должным качеством.
Минусы подхода:
Вовлеченность команды может быть разного уровня.
Найденные точки отказа продукта устраняются с разным приоритетом, зависит от уровня команды.
Разработка медленнее обучается разрабатывать сервисы более отказоустойчивыми.
Конечно, есть и третий подход - это сумма первого и второго подхода, но это крайне редкость. Такой подход, конечно, получает все плюсы первого и второго подхода. И кажется, что такая компания по культуре очень близка к компаниям, где практика Chaos Engineering родилась.
Команду собрали, теперь добрались до испытаний.
5. Испытания
Первый способ - сгенерировать набор различных сценариев, но этот подход не годится для того, чтобы испытывать сотни автоматизированных систем в крупном предприятии.
Второй способ - продумать "модель" испытаний, которую можно тиражировать. Идеи можно и нужно черпать, в том числе из произошедших инцидентов в разных системах, а также создавать дополнительные сценарии.
Перед проведением испытаний определяем состояние испытуемой системы. Данная классификация призвана снизить количество "неполезных" испытаний. Если у вас нет базовой системы, вы не сможете корректно принять решение, деградировала ли система или нет. Если отсутствуют компенсирующие механизмы, например, если у вас есть только один экземпляр БД, то любой сбой в БД приведет к ее отказу, и такие сценарии можно сразу исключить.
![Определяем состояния испытуемой системы Определяем состояния испытуемой системы](https://webcf.waybackmachine.org/web/20240223091149/https://habrastorage.org/getpro/habr/upload_files/ab8/fa3/eb6/ab8fa3eb6cb1bb12d1febb027d869702.png)
vaanbeВиды отказов которые можем эмулировать (примерное распределение):
Ресурсные: Утилизация ЦПУ, памяти, дисков.
Сеть: Задержки, потери, коррупции пакетов.
Контейнерные/клаудные: Kill pods, ресурсная утилизация pods.
Прикладные: Kill, Pause process, Full GC. <<--- в этом слое можно придумать бесчисленное множество кейсов. Все зависит от ваших целей и возможностей.
Для реализации конкретных кейсов и вдохновения можно взять gitbook инструмента Chaos Blade, который мы часто используем, и посмотреть возможные варианты сценариев chaosblade-io.gitbook.io.
В больших предприятиях технический стек от системы к системе не сильно отличается. Это позволяет тиражировать созданную "модель" на десятки, а иногда и сотни систем с небольшой адаптацией под конкретные особенности каждой системы.
Итак, модель составлена, идем проводить испытания.
Если мы выполняем внедрение в продакшене, рекомендуется выбрать момент с небольшой нагрузкой. Если мы выполняем внедрение в тестовой среде, необходимо подать нагрузку.
6. Оценка результатов
Проводим первые сценарии, собираем логи и просматриваем мониторинг.
Сценарий должен иметь достаточную продолжительность, не 1 минуту, так как иногда эмуляция отказа не успевает оказать должное воздействие. Рекомендуется устанавливать продолжительность эмуляции примерно 10 минут, после чего системе следует дать время на восстановление.
В команде могут возникнуть споры по интерпретации результатов. Давайте для этого рассмотрим примеры графиков transaction per second.
![Пример 1. График transaction per second Пример 1. График transaction per second](https://webcf.waybackmachine.org/web/20240223091149/https://habrastorage.org/getpro/habr/upload_files/f22/ff8/1ac/f22ff81acce3201f800e5e8517bcd121.png)
Время эмуляции отказа: 00:30 - 00:40.
Выводы, которые можно сделать:
Негативное поведение.
Деградация наблюдается на протяжении всего периода испытания, система не попыталась восстановиться во время эмуляции.
После остановки эмуляции началось восстановление, примерно через 3-5 минут.
Обратите внимание на красный график после начала стабилизации, это ошибки. Если объем трафика будет большим, есть риск того, что ошибки могут "залить" соседние сервисы заведомо плохими транзакциями.
![Пример 2. График transaction per second Пример 2. График transaction per second](https://webcf.waybackmachine.org/web/20240223091149/https://habrastorage.org/getpro/habr/upload_files/68d/6fd/d8a/68d6fdd8aa82fe64ef6493dfb92c8e4e.png)
Время эмуляции отказа: 17:12 - 17:22.
Выводы, которые можно сделать:
Негативное - позитивное поведение.
Сервис сильно деградировал в первые несколько минут, требовалось много времени на переключение на балансировщике - это негативное поведение.
Однако мы отчетливо видим, что сервис, несмотря на продолжающуюся эмуляцию, активно восстанавливается и примерно через 23 минуты полностью восстанавливается. Мы выключаем эмуляцию, начинается естественный ребаланс в кластере в первоначальное состояние, поэтому видна еще небольшая просадка входящего трафика.
![Пример 3. График transaction per second Пример 3. График transaction per second](https://webcf.waybackmachine.org/web/20240223091149/https://habrastorage.org/getpro/habr/upload_files/750/bf4/721/750bf4721a7232cafdb89f506b2f822c.png)
Как думаете, позитивное или негативное поведение?
Время эмуляции отказа: 17:44 - 17:54.
Выводы, которые можно сделать:
Сервис незначительно деградировал. На 54-й минуте сервис начал восстанавливаться, но...
Полного восстановления не произошло, мы потеряли объем примерно в 2,5К транзакций. Сервис продолжает деградировать несколько часов, потеряв половину от своего трафика.
В реальных инцидентах в продакшн не редкость, когда инцидент случается, скажем, в 3 утра и не заметен для системы, а проявляется в 12 часов дня во время пика обслуживания клиентов.
Конечно же, если мы говорим о Enterprise, для проведения эмуляций в сотнях систем и учета всех испытаний - требуется автоматизация.
Этот вопрос очень обширный, мы обсудим его в следующей части и подробно рассмотрим несколько архитектур сервисов, которые можно найти в OpenSource.
* отдельный респект за ревью статьи @vaanbe
Автор: Дмитрий Якубовский