Свое или чужое: почему и как мы делаем нашу хаос-платформу

Надежность инфраструктуры обычно существует где-то между красивыми SLO на слайдах и суровой реальностью продакшена. В Райффайзен Банке решили перестать верить в планы на бумаге и начали регулярно «ломать» собственные системы — осознанно и по науке ^[1]. В этой статье руководитель команды разработки организации расскажет, как они пришли к хаос-инжинирингу, почему не смогли использовать готовые инструменты и как за несколько месяцев собрали собственную платформу для проверки отказоустойчивости и уверенности в том, что сервисы действительно выдержат сбои.

Меня зовут Кирилл Пономарёв, я руковожу командой разработки хаос-платформы Райффайзенбанка. У нас есть некоторая инфраструктура, которая используется для работы наших СУБД, приложений, очередей сообщений и т.д.

По моему мнению, есть четыре самые частые причины проблем со стороны поставщика услуг, которые служат причиной недовольства пользователей:

1. Баги приложения;

2. Ошибки ^[2] в конфигурировании;

3. Авария инфраструктуры;

4. Человеческий фактор.

С багами приложения и ошибками конфигурации мы можем разобраться тестами и роллбэками. С человеческим фактором — улучшением процессов путем обучения ^[3] и консультаций команд. Что делать с инфраструктурой? На первый взгляд, это очень легкий вопрос. Есть три возможности всё улучшить:

• Резервирование площадок;

• Кластеризации;

• Резервное копирование.

Но как это проверить? Мне повезло. Когда я пришел в Райф, уже были планы для Disaster Recovery. Это большой объемный документ, где пишется, что делать, что может пойти не так, к кому бежать, ссылки на кук-буки и так далее.

Существует круговая диаграмма, по которой команды, проверяют этот план. 

Обратите внимание ^[4] на пункт «Testing the Plan». План надо как-то протестировать, потому что написать, что все развалится: это хорошо, но нужно это доказать. Поэтому мы регулярно проводим Disaster Recovery-тесты. То есть берем и сознательно что-то ломаем: перегружаем память ^[5], выключаем целый ЦОД или еще что-нибудь, и смотрим на результаты.

Мы делаем это для следующих вещей:

• Повышаем надежность;

• Сокращаем время простоя, потому что знаем, что может случиться, и можем об этом заранее подумать;

• Самое главное, улучшаем пользовательский опыт ^[6], потому что никому не хочется заходить в приложение, где ничего не работает;

• Это просто весело — очень прикольно что-то разломать.

Последний пункт, возможно, не довод, поэтому оставим только три. И как будто бы все, наш банк на коне, все довольны, спасибо.

Однако в жизни все немного сложнее. Мы все знаем про надежность и отказоустойчивость.

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

При чем тут хаос-инжиниринг

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

Как работает хаос-инжиниринг видно на иллюстрации.

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

Мы делали его не централизованно, поэтому решили поискать инструмент, который поможет сделать это все качественно и просто.

Опробованные инструменты

Перед созданием своей платформы мы протестировали Litmus и Chaos Mesh. Расскажу про них, чтобы было понятно, почему стали разрабатывать свое решение.

Почему не подошел Litmus

Примерно так выглядит структура Litmus:

На иллюстрации три треугольника — Control Plane, Chaos Center и подчинённых или тех, на ком выполняется эксперимент (речь о клиентах, которые подключены к контрол плейну и выполняют хаос-эксперименты).

У Litmus много проблем. Например для работы нужно сначала установить Litmus в кластер, потом установить CLI, затем через CLI создать проект. Однако, напрямую из интерфейса этого сделать нельзя, но нужно сделать кое-что другое: создать окружение внутри и подключить ChaosHub.

ChaosHub подключается извне — это репозиторий на GitHub. Сложность в том, что у нас в банке закрытый контур, мы не можем это сделать напрямую.

Далее нужно установить агентскую часть в клиентский кластер при помощи CLI (работает только с K8S), потом адаптировать все образы.

А ещe Litmus запускает эксперименты в несколько этапов через несколько контейнеров. При этом интерфейс решения крайне неудобный.

Почему не подошел Chaos Mesh

В случае с Chaos Mesh нас интересует эта схема.

На ней мы видим набор YAML файлов, Control Plane и узлы выполнения — ничего искать не надо, можем выполнять это и в Kubernetes, все замечательно.

Отказались мы по другим причинам.

• Отсутствие аутентификации/авторизации. Точнее аутентификация есть, но она работает через секрет K8S: поставили, зашли в K8S, нашли секрет, посмотрели его, и только тогда вошли. Авторизации нет, а значит вы не можете поделить, разграничить права доступа.

• Нет кластеризации. Кластеризация была только в альфе, и не такая, как хотелось бы. Из одного Chaos Mesh можно сделать еще много маленьких, но он не будет собирать все данные, агрегировать их и прочее.

• Использование etcd для хранения данных. Chaos Mesh все хранит в Kubernetes. То есть это дополнительные ресурсы, которые нагружают и без того нагруженные etcd, особенно если у вас огромный кластер. Единственный вариант от них избавиться — это архивировать, тогда он сбросит их в Postgres. 

• Пуш-модель работы с агентами.

На последнем остановлюсь подробнее.

Есть эксперимент Network loss. Он хорош тем, что вы можете полностью заблокировать трафик какого-нибудь хоста и посмотреть, что произойдет: split-brain, как переводятся мастера и так далее. Control Plane посылает POST запрос на хост, где работает агент. Хост теряет сеть. Дальше Control Plane посылает DELETE запрос. Но, т. к. он никуда не может послать, потому что сети нет — машина просто исчезает. Не в прямом смысле, но вы ничего не можете сделать, кроме как зайти через удаленную консоль и сбросить правила Traffic Control.

В целом, нам понравился Chaos Mesh, поэтому можно подумать от доработке. Задачи следующие:

• добавить нормальную авторизацию;

• переделать механизмы получения задач;

• понять, позволяет ли лицензия нам это сделать.

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

Требования к платформе

Определимся, чего мы хотим от хаос-платформы.

1. Для начала мы хотим иметь одно место, из которого будем запускать тесты. Туда будет заходить инженер, разработчик, тестировщик и запускать эксперименты. 

2. Историчность. Нам нужно сохранять, какие эксперименты были, чтобы мы могли на основе этой истории сформировать понимание, насколько команда хорошо покрывает свои сервисы и насколько они растут.

3. Нам нужен Role Based Access Control. Мы хотим, чтобы можно было поделить зоны ответственности между командами. 

4. Возможность аудита. Мы все-таки банк, а эта платформа может сломать многое, поэтому нам нужна отдельная БД, в которой мы будем хранить данные, но уже в подготовленном виде, то есть не просто бэкапы, а именно так, чтобы сделать выборку.

5. Полная автоматизация от создания Change Request до его закрытия с отчетом. При больших тестах, которые могут задеть критически важные узлы, мы создаем специальные Change Requests. Мы хотим, чтобы человек зашел, нажал две кнопки, и у него весь процесс прошел автоматизировано.

6. PostgreSQL. Мы хотим Postgres, потому что умеем с ним работать, и потому что у нас есть команда, которая предоставляет нам Postgres as a Service.

7. Отсутствие внешних зависимостей. Это не про то, что мы пишем библиотеки и все остальное сами. Это про лишние шаги в процессе. Например, в Chaos Mesh, чтобы тестировать нагрузку CPU и памяти, используется stress-ng. То есть вам нужно сначала поставить stress-ng, только потом вы сможете проводить свои тесты.

8. Возможность проводить тесты с ресурсами Kubernetes и Linux. Из одного места, с одними агентами, собранными под разные архитектуры, но одна платформа — много действий.

9. Pull-модель работы агента с платформой. Она позволит нам делать все, что мы хотим.

Разработка решения

В январе 2024 собираем команду, выбираем микросервисную архитектру DOA (Data Oriented Architecture, DOA. В архитектуре, ориентированной на данные, все микросервисы работают с одними и теми же данными), язык разработки Go и пишем. В июле того же года MVP готов. 

К моменту написания статьи у нас есть такие результаты:

Каждый сервис ходит в storage и работает ровно с теми логическими операциями, которые мы на него отдали.

Core отвечает за:

• редактирование сценария;

• просмотр проектов;

• просмотр отчетов по сценариям.

Auth отвечает за:

• авторизация;

• аутентификация;

• получение списка разрешенных проектов.

Он читает из Postgres то, что нужно для сравнения

Gateway отвечает за:

• добавление агентов;

• получение агентов;

• запуск сценариев;

• запись отчетов.

Мы логически поделили так, чтобы сервисы не записывали один и тот же объект. То есть где-то читаем, где-то записываем, но не на двух сервисах сразу.

Какой получилась платформа

Решение отчасти уже готово, давайте посмотрим, отвечает ли оно заложенным требованиям.

• Одно место, из которого можно запускать тесты. Это мы сделали.

Единая платформа есть, сделали фронтенд, выглядит она вот так:

• Историчность. Да, у нас хранятся все выполненные отчеты, удалить можно только не запущенные. Мы видим, что и как делали люди.

• Role Based Access Control. У нас есть RBAC, авторизация, разделение по проектам. Всё по классике и похоже на GitLab.

• Возможность проводить тесты с ресурсами Kubernetes и с OC. 

Полностью это сделать еще не получилось. Мы можем работать с Kubernetes и Linux, выполнять эксперименты с подом. Обе задачи еще делаются, приходится много экспериментировать, очень часто приходится лезть в API Kubernetes, спускаться к ядру. Поэтому двигаемся не так быстро, как хотелось бы, но прогресс налицо.

• Pull-модель работы агента с платформой. Эту цель мы достигли.

Теперь, когда наш целевой хост теряет сеть, агент держит его в таком состоянии, а когда счетчик заканчивается — хост возвращает себе сеть и соединение с Control Plane.

Осталось еще несколько поинтов:

• PostgreSQL. Postgres есть, здесь ничего сложного, просто работаем с Postgres. 

• Полная автоматизация: от создания Change Request до его закрытия с отчетом. Сейчас мы сделали интеграцию с нашей Change Management системой. Еще допиливаем, но работает.

• Возможность аудита. Складываем с помощью сервиса в отдельную базы подготовленные данные,которые могут пригодиться для ИБ или для наших исследований.

• Отсутствие внешних зависимостей

С последним пунктом не все гладко, остановлюсь на нем подробнее. Мы избавились от stress-ng, но столкнулись с тем, что используем syscalls. У нас стоит AlmaLinux. Чтобы эти конкретные syscalls использовать на Alma, нам нужно доставить kernel extra modules. Мы доставляем, они тянут за собой ядро, перезагружаем, все начинает работать. Пока мы оставили все как есть, но ещё подумаем, как можно обойти.

• Тесты безопасности. Мы полностью прошли все application security, пентесты, и все у нас сейчас хорошо.

Как работает решение

Для примера запустим эксперимент, где участвуют фронт, Core, Gateway и агенты. 

На фронтенде пользователь формирует эксперименты, они выглядят как сценарии, в них есть блоки с какими-то настройками. После того, как пользователь нажимает СОХРАНИТЬ, эксперимент становится сценарием тестирования, отправляется в Core, и тот записывает его в Postgres. После того, как сценарий оказывается в БД, его можно изменить, удалить или запустить. После старта сценария из Postgres его забирает Gateway, разбивает на эксперименты, в соответствии с порядком выполнения: тесты могут идти параллельно, последовательно, параллельно-последовательно и в разных комбинациях. Далее Gateway раздаёт эксперименты агентам в порядке, который назначил пользователь. При этом юзер просто подвинул блок в интерфейсе.

Потом эксперимент инвертируется в репорт. Далее он снова отправляется в Gateway, сервис пишет его в Postgres. И в конце Core читает отчет из Postgres и отдает пользователю. 

Вот несколько графиков, иллюстрирующих работу системы.

Вы можете не поверить, но эта точеная пика — это наш агент. В какой-то момент мы ему сказали убить CPU, и он это сделал. Затем предложили заполнить файловую систему

Мы выбираем фолдер, в котором создадим большое количество файлов. Агент создал файлы, место было занято, затем, файлы были удалены, и место вернулось.

А это потеря сети (просадка линка)

Я минуту запускал тест, в эту минуту хост вообще не мог получить никакой трафик.

Что дальше?

Расскажу, что еще хотим добавить.

• Полная интеграция Change Management (у нас остался долг).

• Веб-хуки.

• Запуски по расписанию.

• Автоматизированные тесты без участия человека — назначил запуск и ушёл.

• Оценка покрытия.

• Готовые отчеты прямо в виде PDF.

• Страница аналитики.

• Создание Disaster Recovery Plan.

• Работы с Windows.

Оценим пользу от платформы

Какую пользу мы приносим. Во-первых, мы уменьшаем затраты. У нас есть платформа, в которой мы это все накликали и пошли пить чай, больше ничего делать не нужно. 

• Уменьшение затрат на проведение тестов по проверке отказоустойчивости.

• Единый инструмент вместо рук, ansible и shell.

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

• Историчность и возможность оценки покрытия.

• Повышение отказоустойчивости.

• Улучшение опыта клиентов.

Это самое важное для нас, потому что чем меньше мы падаем, тем клиенты радостнее.

Однако у нас есть техдолг:

1. Повышение надежности, чтобы повысить лояльность клиентов.

2. Chaos Engineering: инструменты для проведения экспериментов. Писать ansible-роли руками накладно.

Есть еще и большая проблема: ни один из инструментов не покрыл наши потребности ^[7], поэтому мы решили писать свое.

А еще мы выкладываемся в open source. Мы на пути, но надо подождать.

Выводы и советы

Наш главный девиз: «Делай хорошо — будет хорошо». Он нам помог справиться. Также мы сделали следующие выводы

• Шатайте продуктовый контур. Не надо экспериментировать с DEV, тестами и превью. Это не даст вам никакой информации, не поможет повысить лояльность клиентов и проверить свою надежность.

• Не бойтесь экспериментов. Оцените, подумайте, что и как можно сделать, начните с малого, но начните. Я не поверю вам, если вы скажете: «У нас все надежно, мы все по книжке сделали». 

• Написать работающий сервис за 4 месяца — реально, но тяжко. Советую после этого брать отпуск, потому что выгораешь крайне сильно.

• Признавайте ошибки и не откладывайте в долгий ящик.

Это контр-пункт первому пункту. Я всегда говорю, что если вы увидели, что есть какая-то проблема или что-то не работает, не нужно из этого формировать техдолг. Постарайтесь решить это заранее, потому что как известно техдолг, как снежный ком, будет только больше и больше. Потом с этим будет сложно разобраться. Мы все ошибаемся, мы все люди, просто нужно признать ошибку, заложить время, потратить его и переделать.

А чтобы узнать больше полезного, что может пригодится в работе, приходите на конференцию развития по интеграции процессов разработки, тестирования и эксплуатации DevOps Conf! ^[8] Вас ждёт много практики, интерактива и нетворкинга. Конференция развития — это инструмент решения задач, а не потребления контента.