Chaos Engineering Enterprise Version. Часть 2
Продолжаем разбираться в построении процесса 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 --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.
Пример 1. График transaction per second
Время эмуляции отказа: 00:30 — 00:40.
Выводы, которые можно сделать:
Негативное поведение.
Деградация наблюдается на протяжении всего периода испытания, система не попыталась восстановиться во время эмуляции.
После остановки эмуляции началось восстановление, примерно через 3–5 минут.
Обратите внимание на красный график после начала стабилизации, это ошибки. Если объем трафика будет большим, есть риск того, что ошибки могут «залить» соседние сервисы заведомо плохими транзакциями.
Пример 2. График transaction per second
Время эмуляции отказа: 17:12 — 17:22.
Выводы, которые можно сделать:
Негативное — позитивное поведение.
Сервис сильно деградировал в первые несколько минут, требовалось много времени на переключение на балансировщике — это негативное поведение.
Однако мы отчетливо видим, что сервис, несмотря на продолжающуюся эмуляцию, активно восстанавливается и примерно через 23 минуты полностью восстанавливается. Мы выключаем эмуляцию, начинается естественный ребаланс в кластере в первоначальное состояние, поэтому видна еще небольшая просадка входящего трафика.
Пример 3. График transaction per second
Как думаете, позитивное или негативное поведение?
Время эмуляции отказа: 17:44 — 17:54.
Выводы, которые можно сделать:
Сервис незначительно деградировал. На 54-й минуте сервис начал восстанавливаться, но…
Полного восстановления не произошло, мы потеряли объем примерно в 2,5К транзакций. Сервис продолжает деградировать несколько часов, потеряв половину от своего трафика.
В реальных инцидентах в продакшн не редкость, когда инцидент случается, скажем, в 3 утра и не заметен для системы, а проявляется в 12 часов дня во время пика обслуживания клиентов.
Конечно же, если мы говорим о Enterprise, для проведения эмуляций в сотнях систем и учета всех испытаний — требуется автоматизация.
Этот вопрос очень обширный, мы обсудим его в следующей части и подробно рассмотрим несколько архитектур сервисов, которые можно найти в OpenSource.
* отдельный респект за ревью статьи @vaanbe
Автор: Дмитрий Якубовский
