Принципы и цикл хаос-инженерии

Updated Jul 2026

Что такое хаос-инженерия?

Хаос-инженерия — это дисциплина экспериментирования с системой для укрепления уверенности в её способности выдерживать нештатные условия. Она была создана в Netflix с появлением Chaos Monkey в 2011 году и с тех пор стала неотъемлемой практикой для любой организации, эксплуатирующей распределённые системы.

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

Цикл хаос-инженерии

Каждый хаос-эксперимент проходит пятифазный цикл:

  +-------------------+
  | 1. Define Steady  |
  |    State          |
  +--------+----------+
           |
           v
  +--------+----------+
  | 2. Hypothesize    |
  |    (What should   |
  |     survive?)     |
  +--------+----------+
           |
           v
  +--------+----------+
  | 3. Inject Failure |
  |    (Controlled)   |
  +--------+----------+
           |
           v
  +--------+----------+
  | 4. Observe System |
  |    Behavior       |
  +--------+----------+
           |
           v
  +--------+----------+
  | 5. Learn & Fix    |
  |    (or confirm    |
  |     resilience)   |
  +--------+----------+
           |
           +---------> Repeat

Фаза 1: Определение устойчивого состояния

Прежде чем что-либо ломать, определите, как выглядит «нормальная работа», с помощью количественных метрик. Это ваша базовая линия.

Хорошие определения устойчивого состояния:

• «Наш сервис оформления заказов обрабатывает 500 запросов/с при p99 задержке менее 800 мс и доле ошибок менее 0,1%.»
• «Письма с подтверждением заказа отправляются в течение 30 секунд после покупки для 99,5% заказов.»
• «Сервис поиска возвращает результаты менее чем за 200 мс для 95% запросов.»

Плохие определения устойчивого состояния:

• «Система работает нормально.» (Неизмеримо)
• «CPU загружен менее 80%.» (Метрика ресурсов, а не пользовательского опыта)
• «Нет сработавших алертов.» (Отсутствие алертов не является доказательством работоспособности)

Ключевое различие: устойчивое состояние должно определяться в терминах видимого пользователю поведения, а не инфраструктурных метрик.

Фаза 2: Формулировка гипотезы

Сформулируйте конкретную гипотезу о том, что система должна делать при возникновении сбоя. Гипотеза должна быть фальсифицируемой.

Примеры:

• «Если мы уничтожим 50% подов сервиса оформления заказов, оставшиеся поды должны выдержать нагрузку при p99 задержке менее 2 секунд и без ошибок, видимых пользователям.»
• «Если мы введём 500 мс сетевой задержки между сервисом заказов и сервисом платежей, заказы всё равно должны завершаться в течение 5 секунд.»
• «Если основная база данных переключится на реплику, трафик чтения должен испытать деградацию не более 5 секунд.»

Фаза 3: Внедрение сбоя

Применяйте сбой контролируемым образом с чёткими границами:

• Масштаб. Какие компоненты затронуты?
• Длительность. Как долго длится эксперимент?
• Радиус поражения. Сколько пользователей может быть затронуто?
• Аварийное отключение. Как немедленно прекратить эксперимент при возникновении проблем?

Распространённые типы сбоев:

Фаза 4: Наблюдение

Мониторьте систему во время и после эксперимента. Сравните фактическое поведение с вашей гипотезой. Ключевые наблюдения:

• Осталась ли система в рамках определения устойчивого состояния?
• Сколько времени заняло восстановление?
• Были ли затронуты пользователи? Сколько? На какое время?
• Сработали ли алерты корректно? Была ли уведомлена правильная команда?
• Активировались ли механизмы автомасштабирования или самовосстановления?

Фаза 5: Обучение и исправление

Каждый эксперимент даёт один из трёх результатов:

1. Гипотеза подтверждена. Система корректно обработала сбой. Задокументируйте механизм устойчивости и запланируйте регулярное повторение эксперимента.
2. Гипотеза опровергнута. Система деградировала сверх допустимых пределов. На самом деле это самый ценный результат — вы обнаружили слабое место раньше своих клиентов. Заведите баг, исправьте его и перезапустите эксперимент.
3. Неожиданное поведение. Система повела себя непредсказуемым образом. Это распространённое явление, которое часто выявляет недостаточную наблюдаемость, неверные предположения или каскадные пути отказа.

Пять принципов хаос-инженерии

1. Начинайте с гипотезы об устойчивом состоянии

Каждый эксперимент должен определять, как выглядит «нормальная работа», прежде чем внедрять сбой. Без измеримой базовой линии вы не сможете определить, прошёл эксперимент или провалился.

2. Варьируйте реальные события

Моделируйте то, что действительно происходит в продакшене, а не теоретические сбои. Расставляйте приоритеты по вероятности и воздействию:

3. Проводите эксперименты в продакшене

Стейджинг-среды обманывают. У них другие объёмы данных, другие паттерны трафика, другая сетевая топология и часто другие конфигурации. Единственный способ по-настоящему валидировать устойчивость — тестировать в продакшене с мерами предосторожности.

Путь постепенного внедрения:

1. Начните в среде разработки (убедитесь, что эксперимент работает)
2. Запустите в стейджинге (валидируйте реакцию системы)
3. Запустите в продакшене в часы низкого трафика (валидируйте на реальной инфраструктуре)
4. Запустите в продакшене в обычные часы (валидируйте под реальной нагрузкой)
5. Запустите в продакшене непрерывно (докажите постоянную устойчивость)

4. Автоматизируйте эксперименты для непрерывного выполнения

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

# Example: CronJob for weekly chaos experiment
apiVersion: batch/v1
kind: CronJob
metadata:
  name: weekly-pod-kill-chaos
spec:
  schedule: "0 10 * * 3"  # Every Wednesday at 10 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: chaos-runner
            image: litmuschaos/litmus-checker:latest
            command: ["./run-experiment", "--config", "/etc/chaos/pod-kill.yaml"]

5. Минимизируйте радиус поражения

Используйте feature-флаги, разделение трафика и автоматический откат для ограничения воздействия хаос-экспериментов:

• Начинайте с малого. Уничтожьте один под, прежде чем уничтожать 50%.
• Используйте канареечный трафик. Направляйте только внутренний или тестовый трафик на затронутый компонент.
• Задайте автоматические условия прекращения. Если доля ошибок превышает 5%, немедленно прекратите эксперимент.
• Проводите в часы низкого трафика, пока не наберёте уверенность в дизайне эксперимента.
• Всегда имейте аварийное отключение. Каждый эксперимент должен быть остановлен за секунды.

Распространённые ошибки в хаос-инженерии

Получение одобрения для хаос-инженерии

QA-архитекторам часто приходится убеждать заинтересованные стороны, что намеренное разрушение продакшена — хорошая идея. Преподнесите это так:

1. «Мы не ломаем вещи. Мы выясняем, как они ломаются.» Сбои уже существуют как возможности. Хаос-инженерия находит их проактивно.
2. «Каждый крупный сбой — это незапланированный хаос-эксперимент.» Вопрос не в том, произойдут ли отказы, а в том, обнаружите ли вы их на своих условиях или ваши клиенты обнаружат их на своих.
3. «Хаос-эксперименты снижают серьёзность инцидентов.» Команды, регулярно практикующие хаос, быстрее восстанавливаются, потому что уже отработали реагирование.
4. «Начните в стейджинге, перейдите в продакшен.» Это успокаивает заинтересованные стороны, что вы действуете не безрассудно.

Документируйте каждый результат эксперимента, особенно обнаруженные и исправленные слабые места. Послужной список «мы обнаружили и исправили X до того, как это затронуло клиентов» — самый сильный аргумент в пользу продолжения практики.