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

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

Ключевая идея: вместо ожидания неожиданных сбоев, проактивно инъектировать сбои и наблюдать реакцию системы.

Принципы

  1. Сформулируйте гипотезу о стабильном состоянии. Определите «нормальное»: error rate, латентность, throughput.
  2. Варьируйте реальные события. Инъектируйте реальные сбои: крэши, сетевые партиции, заполнение диска.
  3. Проводите эксперименты в продакшене. Начинайте в staging, продвигайтесь к продакшену.
  4. Автоматизируйте для непрерывного выполнения.
  5. Минимизируйте радиус поражения. Начинайте с малого.

Жизненный цикл эксперимента

Шаг 1: Определение стабильного состояния

Error rate < 0.1%, P95 < 200мс, health checks проходят, завершение заказов > 99%.

Шаг 2: Гипотеза

«Если мы завершим один инстанс платёжного сервиса, система продолжит обработку платежей без роста error rate.»

Шаг 3: Проектирование

  • Цель: Платёжный сервис, один инстанс
  • Тип сбоя: Завершение процесса
  • Длительность: 5 минут
  • Критерии прекращения: Error rate > 1% или P95 > 1 секунды

Шаг 4: Выполнение

С активным мониторингом и готовым kill switch.

Шаг 5: Анализ

Сравнение метрик во время и после эксперимента со стабильным состоянием.

Шаг 6: Исправление и повторение

Типы экспериментов

ЭкспериментЧто тестируетПример
Завершение инстансаАвто-масштабирование, балансировкаУбить случайный под/VM
Сетевая задержкаОбработка таймаутов, retryДобавить 500мс задержки
Сетевая партицияКонсистентность, split-brainБлокировать трафик между сервисами
Заполнение дискаЛогирование, обработка данныхЗаполнить диск на 100%
Стресс CPU/памятиThrottling, лимиты ресурсовПотребить 90% CPU
Сбой зависимостиCircuit breakers, fallbacksСделать внешний API недоступным

Инструменты

ИнструментТипЛучше всего для
Chaos MonkeyOpen source (Netflix)Случайное завершение инстансов
LitmusOpen source (CNCF)Kubernetes-нативные эксперименты
GremlinSaaSEnterprise chaos-as-a-service
ToxiproxyOpen source (Shopify)Симуляция сетевых условий

Упражнение: Спроектируйте хаос-эксперимент

Ваше e-commerce приложение: API gateway, сервис продуктов, корзина, платежи, уведомления, PostgreSQL, Redis. Спроектируйте три эксперимента возрастающего риска.

Решение

Эксперимент 1: Сбой кэша Redis (Низкий риск)

Гипотеза: При недоступности Redis приложение продолжает работу через fallback к БД. Инъекция: Остановить Redis-контейнер на 5 минут. Ожидание: Время ответа растёт до 500-800мс, без ошибок.

Эксперимент 2: Сбой инстанса платежей (Средний риск)

Гипотеза: При гибели одного из трёх инстансов балансировщик перенаправляет на здоровые. Инъекция: Убить под платёжного сервиса. Ожидание: Kubernetes перезапускает за 30с. Без неуспешных платежей.

Эксперимент 3: Сетевая партиция (Повышенный риск)

Гипотеза: При недоступности сервиса инвентаря сервис продуктов отдаёт кэшированные данные. Инъекция: Блокировать сеть между product-service и inventory-service на 3 минуты.

Ключевые выводы

  1. Хаос-инжиниринг — проактивное тестирование устойчивости
  2. Всегда определяйте стабильное состояние первым
  3. Начинайте с малого и эскалируйте
  4. Автоматизируйте и повторяйте
  5. QA привносит уникальную ценность — навыки проектирования тестов и знание мониторинга