Всем привет! Я давно планировал написать цикл статей на тему Chaos Engineering,
чтобы рассказать о том, как его запускать, пилотировать и, конечно, масштабировать.
Я обладаю большим опытом и знаниями, которые помогут запустить эту практику в
«жестком» и сложном Enterprise, когда у нас идут релизы, а команд десятки. Частично
мы с Максимом Козловым уже делились этой информацией на конференциях CodeFest, ArchDays, DevOops Сonf, TechLead Сonf.

Начало

Направление Chaos Engineering у нас в стране пока еще только набирает популярность. Однако во всем мире пик интереса уже давно прошел, и сейчас Chaos Engineering используется во многих крупных компаниях.

Тренды в направлении DevOps и Cloud от компании InfoQ за 2023 год

Многие уже читали про Chaos Engineering, например, на Хабре есть более десяти
статей про историю его возникновения. Многие знают что эта практика появилась в
Netflix.

В связи с этим мы не будем глубоко вдаваться в историю, а лишь дополним ее
несколькими фактами. На самом деле прародителем Chaos Engineering в Netflix
является программа, которую еще 10 лет назад открыли в Amazon. В 2000-х гг.
Amazon пригласил Jesse Robbins ,бывшего пожарного, проводить так называемые
Game Days в своих Cloud-полигонах. Его прозвали "Master of Disaster", он должен был
отвечать за Website Availability.

Как раз он и организовал практику учений, которые были у пожарных в IT. Спустя
7-10 лет, когда Netflix начал мигрировать свою платформу в Amazone Cloud, эта практика пришлась очень кстати. Именно тогда в ходе проведения испытаний
команда Netflix создала продукт Chaos Monkey, который в скором времени стал
синонимом самой практики Chaos Engineering.

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

Далее Netflix начал раскачивать “качели” новой практики, и она постепенно стала
популярной.

Чуть позже выходцы из Netflix поняли, что на практике Chaos Engineering можно
заработать, и создали известную в узких кругах PaaS платформу Gremlin

При этом стоит сказать, что утилита-эталон практики Chaos Monkey постепенно
теряет актуальность, и на текущий день очень плохо развивается (в год выходит по
3-5 поддерживающих на плаву коммитов https://github.com/Netflix/chaosmonkey/
commits/master).

На фоне развития практики совершенствуются и утилиты, а также сами платформы.

Примерно в 2018-2019 гг. The Cloud Native Computing Foundation (CNCF) решает официально открыть отдельный раздел инструментов Chaos Engineering, который сейчас выглядит вот так:

The Cloud Native Computing Foundation (CNCF). Инструменты для проведения Chaos Engineering испытаний.

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

Chaos и другие типы испытаний

На старте запуска практики в компании обычно возникает вопрос, который входит в ТОП-10 вопросов от бизнеса/инженерных команд:

Chaos Engineering − это ведь то же, что и аварийные учения, проверка DRP-планов, разновидность нагрузочного тестирования или Penetration testing? Так зачем нам еще и он?

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

Из названия не совсем ясно, о чем идет речь. Понятно, что Load testing − это про нагрузку, Pinetration testing − про проникновение в Cyber Security. Chaos же никак не получится перевести корректно. Практику надо было практику назвать Fail tolerance capability engineering, но это очень длинно.
Chaos Engineering стоит на стыке разных методик и включает в себя кусочки других практик. Из аварийных учений и DRP сюда включены проверки переключения кластеров и отказы инфраструктуры. Из Load Testing здесь взята нагрузка как таковая, потому как в ненагруженной системе тестировать нечего.
Ниже предлагаю посмотреть на примерное распределение различных тестов в разрезе
уровней абстракций, которые присутствуют в любой автоматизированной системе.

В данной таблице каждому уровню соответствует набор практик, которые позволяют его проверить. Нагрузочные и интеграционные придумывались, прежде всего, для того, чтобы проверить уровень приложений, Аварийные учения и RDP в целом акцентированы на более низких слоях стека. Сложно представить, что интеграционными тестами мы будем проверять, а сделана ли корректная настройка системного времени c NTP-сервером. Скорее здесь мы обратимся к практике аварийных учений или Chaos Engineering.

За счет наличия определенных сценариев на каждом слое Chaos Engineering часто путают с другими типами тестирования.

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

Value и работа с будущим, которое еще не случилось

Далее возникает вопрос − как же нам показать Value от использования данной практики?

По нашему опыту, он входит в ТОП-10 популярных вопросов практики, так как Chaos Engineering позволяет найти потенциальные уязвимости в автоматизированной системе. Но проявят они себя или нет - это уже что-то из теории вероятности, которая, как известно, относительна.

К тому же если, мы предположим найдем потенциальное место, где система неустойчива и уходит в глубокий down time. От этой найденной точки до ее устранения, выпуска релиза и поставки в продуктивную среду происходит целый процесс, который лежит за рамками этой практики.

Решением данного вопроса занимались многие игроки рынка, алгоритм расчета одновременно и прост, и сложен:

Выбираем испытуемую систему;
Считаем общий downtime системы на похожие инциденты;
Смотрим, как давно были такие инциденты;
Сколько прибыли/пользователей было потеряно за период инцидента;
Как много инженеров работало над тушением пожара во время инцидента и выработке костыля после инцидента;
Другие затраты на фиксацию инцидента.

В следующих частях поговорим об эволюции испытаний в Enterprise.

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

Chaos Engineering Enterprise Version. Часть 1