Хаос-инжиниринг как прививка от возможных проблем распределенных систем

Хаос-инжиниринг как прививка от возможных проблем распределенных систем

Чтобы создавать более устойчивые системы и решать проблемы до того, как они приведут к инцидентам, команды DevOps все чаще обращаются к так называемому хаос-инжинирингу (Chaos Engineering) или хаос-тестированию. Его можно рассматривать как дисциплину экспериментирования для создания системы, которая будет способна противостоять неожиданным сбоям или условиям.

Тестирование разворачиваемого проекта

Представим абстрактный сервис, подготовленный к релизу, с рядом зависимостей – типичная микросервисная экосистема.

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

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

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

При этом юнит- или интеграционное тестирование не может предусмотреть все возможные риски. Например, DDoS-атаки, которые нельзя предсказать с помощью тестирований. И здесь на помощь приходит хаос-инжиниринг.

Хаос-инжиниринг помогает строить систему, подготовленную к рискам

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

Изначально понятие и дисциплину (метод) создал Gregory S. Orzell для тестирования миграции из центра обработки данных компании Netflix в облачные технологии в 2011 году. Для такой крупной компании, как Netflix, перенести весь громадный объем своих компонентов в облако – задача весьма нетривиальная. В процессе разработки метода Gregory S. Orzell искал ответы на вопросы: как перебраться в облако, как быть готовым к отказам в работе микросервисов, как подготовить всю систему к сбоям?

Этапы проведения хаос-инжиниринга

  1. Определение, что такое устойчивое состояние в рассматриваемой системе – метрики, показатели. Какие конкретно метрики снимать – правил не существует, но они должны однозначно показывать, что приложение находится в устойчивом состоянии, и быть зафиксированными.
  2. Выбор контрольной и экспериментальной группы – нет необходимости внедрять хаос во всю систему целиком.
  3. Введение некоторых предположений о состоянии групп. Например: что если конкретный элемент системы перестанет работать или хакеры начнут эксплуатировать уязвимость?
  4. Введение переменных, отражающих реальные события, то есть внедрение предположенных ранее гипотетических проблем в выбранную для эксперимента группу.
  5. Попытка опровергнуть предположения. Хаос-инженеру интересно опровержение предположений, сделанных на третьем этапе, он должен усомниться в том, что приложение устойчиво к проблемам.

Автоматизация

Для успешного проведения хаос-инжиниринга существуют разработанные инструменты. Такие инструменты есть, например, у компании Netflix, поскольку она первой начала заниматься вопросом. Это Chaos Monkey и The Simian Army, а также Chaos Engine, Gremlin, Fault Injection Queries и другие. 

Сегодня востребованы программные SAS-решения, которые охватывают все этапы работы с информацией (сбор, изменения, управление и извлечение данных из различных источников) и выполняют их статистический анализ.

Главная » Статьи » Хаос-инжиниринг как прививка от возможных проблем распределенных систем
a

Свежий выпуск «Люди PRO»

Свежий выпуск «Мультичела»

Читайте также