Всем привет! Я давно планировал написать цикл статей на тему Chaos Engineering,
чтобы рассказать о том, как его запускать, пилотировать и, конечно, масштабировать.
Я обладаю большим опытом и знаниями, которые помогут запустить эту практику в
«жестком» и сложном Enterprise, когда у нас идут релизы, а команд десятки. Частично
мы с Максимом Козловым уже делились этой информацией на конференциях CodeFest, ArchDays, DevOops Сonf, TechLead Сonf.
Начало
Направление Chaos Engineering у нас в стране пока еще только набирает популярность. Однако во всем мире пик интереса уже давно прошел, и сейчас Chaos Engineering используется во многих крупных компаниях.
Многие уже читали про 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, который сейчас выглядит вот так:
Далее мы детально познакомимся с утилитами, но прежде давайте поговорим о типах испытаний.
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.
Автор: Дмитрий Якубовский