Чтобы создавать более устойчивые системы и решать проблемы до того, как они приведут к инцидентам, команды DevOps все чаще обращаются к так называемому хаос-инжинирингу (Chaos Engineering) или хаос-тестированию. Его можно рассматривать как дисциплину экспериментирования для создания системы, которая будет способна противостоять неожиданным сбоям или условиям.
Тестирование разворачиваемого проекта
Представим абстрактный сервис, подготовленный к релизу, с рядом зависимостей – типичная микросервисная экосистема.
Система демонстрирует стабильность, и наступил момент, чтобы развернуть ее на новой машине для производства. Но перед непосредственным запуском в широкое пользование проект должен быть хорошо протестирован.
Обязательной проверке должны подвергнуться следующие элементы:
- сеть, диски, базы данных, библиотеки,
- подсистемы IT-инфраструктуры, обеспечивающие функционирование киберпространства системы и средств информационного взаимодействия,
- внешние сервисы, живущие по собственному таймлайну,
- человеческий фактор – проверка подготовленности сотрудников.
При этом юнит- или интеграционное тестирование не может предусмотреть все возможные риски. Например, DDoS-атаки, которые нельзя предсказать с помощью тестирований. И здесь на помощь приходит хаос-инжиниринг.
Хаос-инжиниринг помогает строить систему, подготовленную к рискам
Хаос-инжиниринг представляет собой набор экспериментов с системой, включающий в том числе и контролируемые сбои, для выявления потенциальных проблем, которые могут возникнуть в продакшн-окружении. Суть хаос-инжиринга построить проект так, чтобы он был готов к реальным проблемам. Он не маскирует решение проблемы тестами, а готовит приложение быть устойчивым к любым сбоям, которые непременно случатся.
Изначально понятие и дисциплину (метод) создал Gregory S. Orzell для тестирования миграции из центра обработки данных компании Netflix в облачные технологии в 2011 году. Для такой крупной компании, как Netflix, перенести весь громадный объем своих компонентов в облако – задача весьма нетривиальная. В процессе разработки метода Gregory S. Orzell искал ответы на вопросы: как перебраться в облако, как быть готовым к отказам в работе микросервисов, как подготовить всю систему к сбоям?
Этапы проведения хаос-инжиниринга
- Определение, что такое устойчивое состояние в рассматриваемой системе – метрики, показатели. Какие конкретно метрики снимать – правил не существует, но они должны однозначно показывать, что приложение находится в устойчивом состоянии, и быть зафиксированными.
- Выбор контрольной и экспериментальной группы – нет необходимости внедрять хаос во всю систему целиком.
- Введение некоторых предположений о состоянии групп. Например: что если конкретный элемент системы перестанет работать или хакеры начнут эксплуатировать уязвимость?
- Введение переменных, отражающих реальные события, то есть внедрение предположенных ранее гипотетических проблем в выбранную для эксперимента группу.
- Попытка опровергнуть предположения. Хаос-инженеру интересно опровержение предположений, сделанных на третьем этапе, он должен усомниться в том, что приложение устойчиво к проблемам.
Автоматизация
Для успешного проведения хаос-инжиниринга существуют разработанные инструменты. Такие инструменты есть, например, у компании Netflix, поскольку она первой начала заниматься вопросом. Это Chaos Monkey и The Simian Army, а также Chaos Engine, Gremlin, Fault Injection Queries и другие.
Сегодня востребованы программные SAS-решения, которые охватывают все этапы работы с информацией (сбор, изменения, управление и извлечение данных из различных источников) и выполняют их статистический анализ.
