Продолжаем разбираться в построении процесса 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. Испытания

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

Второй способ - продумать "модель" испытаний, которую можно тиражировать. Идеи можно и нужно черпать, в том числе из произошедших инцидентов в разных системах, а также создавать дополнительные сценарии.

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

vaanbeВиды отказов которые можем эмулировать (примерное распределение):

Ресурсные: Утилизация ЦПУ, памяти, дисков.
Сеть: Задержки, потери, коррупции пакетов.
Контейнерные/клаудные: Kill pods, ресурсная утилизация pods.
Прикладные: Kill, Pause process, Full GC. <<--- в этом слое можно придумать бесчисленное множество кейсов. Все зависит от ваших целей и возможностей.

Для реализации конкретных кейсов и вдохновения можно взять gitbook инструмента Chaos Blade, который мы часто используем, и посмотреть возможные варианты сценариев chaosblade-io.gitbook.io.

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

Итак, модель составлена, идем проводить испытания.

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

6. Оценка результатов

Проводим первые сценарии, собираем логи и просматриваем мониторинг.

Сценарий должен иметь достаточную продолжительность, не 1 минуту, так как иногда эмуляция отказа не успевает оказать должное воздействие. Рекомендуется устанавливать продолжительность эмуляции примерно 10 минут, после чего системе следует дать время на восстановление.

В команде могут возникнуть споры по интерпретации результатов. Давайте для этого рассмотрим примеры графиков transaction per second.

Время эмуляции отказа: 00:30 - 00:40.

Выводы, которые можно сделать:

Негативное поведение.
Деградация наблюдается на протяжении всего периода испытания, система не попыталась восстановиться во время эмуляции.
После остановки эмуляции началось восстановление, примерно через 3-5 минут.

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

Время эмуляции отказа: 17:12 - 17:22.

Выводы, которые можно сделать:

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

Как думаете, позитивное или негативное поведение?

Время эмуляции отказа: 17:44 - 17:54.

Выводы, которые можно сделать:

Сервис незначительно деградировал. На 54-й минуте сервис начал восстанавливаться, но...
Полного восстановления не произошло, мы потеряли объем примерно в 2,5К транзакций. Сервис продолжает деградировать несколько часов, потеряв половину от своего трафика.

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

Конечно же, если мы говорим о Enterprise, для проведения эмуляций в сотнях систем и учета всех испытаний - требуется автоматизация.

Этот вопрос очень обширный, мы обсудим его в следующей части и подробно рассмотрим несколько архитектур сервисов, которые можно найти в OpenSource.

* отдельный респект за ревью статьи @vaanbe

Автор: Дмитрий Якубовский

Chaos Engineering Enterprise Version. Часть 2