Chaos Engineering Enterprise Version. Часть 1
Всем привет! Я давно планировал написать цикл статей на тему 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 здесь взята нагрузка как таковая, потому как в ненагруженной системе тестировать нечего.
Ниже предлагаю посмотреть на примерное распределение различных тестов в разрезе
уровней абстракций, которые присутствуют в любой автоматизированной системе.
Уровни абстракций vs Типы практик
В данной таблице каждому уровню соответствует набор практик, которые позволяют его проверить. Нагрузочные и интеграционные придумывались, прежде всего, для того, чтобы проверить уровень приложений, Аварийные учения и RDP в целом акцентированы на более низких слоях стека. Сложно представить, что интеграционными тестами мы будем проверять, а сделана ли корректная настройка системного времени c NTP-сервером. Скорее здесь мы обратимся к практике аварийных учений или Chaos Engineering.
За счет наличия определенных сценариев на каждом слое Chaos Engineering часто путают с другими типами тестирования.
Мы с командой обычно показываем данную таблицу тем, кто задает вопросы о необходимости Chaos Engineering. После этого все возражения о целесообразности ее использования снимаются.
Value и работа с будущим, которое еще не случилось
Далее возникает вопрос − как же нам показать Value от использования данной практики?
По нашему опыту, он входит в ТОП-10 популярных вопросов практики, так как Chaos Engineering позволяет найти потенциальные уязвимости в автоматизированной системе. Но проявят они себя или нет — это уже что-то из теории вероятности, которая, как известно, относительна.
К тому же если, мы предположим найдем потенциальное место, где система неустойчива и уходит в глубокий down time. От этой найденной точки до ее устранения, выпуска релиза и поставки в продуктивную среду происходит целый процесс, который лежит за рамками этой практики.
Решением данного вопроса занимались многие игроки рынка, алгоритм расчета одновременно и прост, и сложен:
Выбираем испытуемую систему;
Считаем общий downtime системы на похожие инциденты;
Смотрим, как давно были такие инциденты;
Сколько прибыли/пользователей было потеряно за период инцидента;
Как много инженеров работало над тушением пожара во время инцидента и выработке костыля после инцидента;
Другие затраты на фиксацию инцидента.
В следующих частях поговорим об эволюции испытаний в Enterprise.
Автор: Дмитрий Якубовский
