Developer

Chaos Engineering и проверка отказоустойчивости

↑ Этап 8 · Senior: надёжность, безопасность, платформа

По желанию~8 мин чтенияУровень: senior

Зачем это на собесе

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

Что это

Chaos Engineering — дисциплина экспериментов над системой для выявления слабых мест и повышения уверенности в её способности выдерживать турбулентные условия в продакшне (Netflix Chaos Monkey → Principles of Chaos). Цель — не «сломать», а научиться и улучшить устойчивость до реального инцидента.

Принципы

  1. Определить устойчивое состояние (steady state): измеримые показатели нормального поведения (SLI: успешность, латентность, бизнес-метрики).
  2. Сформулировать гипотезу: «при отказе одного пода/зоны/зависимости steady state сохранится (ошибки < 1%, p95 < 500 мс)».
  3. Внести реалистичные события (отказ инстанса, задержка сети, недоступность зависимости, нехватка ресурсов, сбой DNS/времени).
  4. Наблюдать метрики и сравнивать с контрольной группой/базой.
  5. Опровергнуть гипотезу — значит найти уязвимость; исправить.
  6. Минимизировать радиус поражения (blast radius): начинать с малого (один под, 1% трафика, staging), автоматическая остановка (abort conditions) при превышении порогов.
  7. Автоматизировать и повторять (в CI/по расписанию), расширять на прод по мере зрелости.

Цикл эксперимента

Steady state → Гипотеза → План (масштаб, условия остановки, откат, оповещения) → Запуск → Наблюдение → Анализ → Улучшения → Повтор

Подготовка: мониторинг и алерты работают (иначе ничего не увидим), есть откат/кнопка остановки, заинтересованные предупреждены (game day), выбрано безопасное окно, проверены зависимости.

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

КатегорияПримеры
Инфраструктураубить ВМ/ноду, отключить зону доступности, заполнить диск, CPU/память-стресс, потеря сетевого интерфейса
Kubernetesудаление подов, отказ ноды (drain/kill), эвикция, сбой kubelet/CNI, нехватка ресурсов, отказ etcd/API-сервера
Сетьзадержка (latency), потери пакетов, дублирование, разрыв соединений, партиции (split-brain), ограничение пропускной способности, DNS-сбои, блокировка портов
Приложение/зависимостинедоступность БД/кэша/очереди/внешнего API, медленные ответы (latency injection), ошибки HTTP 5xx (fault injection), истечение сертификата, исчерпание пула соединений/потоков
Состояние и данныепотеря реплики БД, failover, отставание репликации, повреждение/потеря сообщений, сбой бэкапа и восстановление
Время и часысдвиг времени (clock skew) — ломает токены, сертификаты, кворумы
Процессы/людиотказ дежурного, недоступность системы доступа (учения реагирования), потеря runbook
Безопасностькомпрометация учётной записи (red team), отзыв секретов/ключей

Инструменты

ИнструментОсобенности
Chaos Mesh (CNCF)Kubernetes: PodChaos, NetworkChaos, IOChaos, StressChaos, TimeChaos, DNSChaos, HTTPChaos, Workflow, Dashboard
LitmusChaos (CNCF)Kubernetes, ChaosHub экспериментов, ChaosCenter
Gremlinкоммерческая платформа (SaaS), широкий набор, безопасность
AWS FIS, Azure Chaos Studio, GCPоблачные сервисы внедрения сбоев
Chaos Monkey / Simian ArmyNetflix (случайное завершение инстансов)
Toxiproxyпрокси для внедрения сетевых сбоев между сервисами (тесты)
PumbaDocker: kill, pause, netem
tc/netem, stress-ng, iptables, killручные эксперименты на Linux
Istio/Linkerd fault injection, Envoyзадержки и ошибки на уровне mesh
k6 + xk6-disruptorнагрузка + внедрение сбоев
Steadybit, ChaosToolkitоркестрация экспериментов как код
# Chaos Mesh: задержка сети 200 мс для подов api на 5 минут
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata: { name: api-latency, namespace: chaos-testing }
spec:
  action: delay
  mode: fixed-percent
  value: "50"
  selector: { namespaces: [clinic], labelSelectors: { app: api } }
  delay: { latency: 200ms, jitter: 50ms, correlation: "50" }
  duration: 5m
---
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata: { name: kill-one-api, namespace: chaos-testing }
spec:
  action: pod-kill
  mode: one
  selector: { namespaces: [clinic], labelSelectors: { app: api } }

Простейший ручной эксперимент: kubectl delete pod -l app=api --field-selector ... при нагрузке k6, наблюдая дашборд SLI и проверка, что PDB/реплики/readiness справились.

Game Days

Плановое учение: команда собирается, проводит серию экспериментов/сценариев по заранее подготовленному плану, отрабатывает реакцию (мониторинг, эскалации, runbooks, коммуникации, откат), фиксирует выводы.

Структура: цели и гипотезы → роли (руководитель, наблюдатели, «хаос»-оператор, дежурные) → сценарии (с нарастающей сложностью) → правила безопасности (стоп-слово, условия остановки) → выполнение → разбор (blameless) → задачи на улучшение.

Сценарии: потеря зоны доступности (проверка multi-AZ и запаса ёмкости), отказ БД/failover (Patroni), истечение сертификата, недоступность IdP, удаление секрета, отказ реестра образов, деградация внешнего API, шторм ретраев, массовый рестарт, восстановление из бэкапа, отказ мониторинга («слепой» режим).

Что проверять

  • HA и восстановление: реплики, PDB, anti-affinity, авто-перезапуск, время failover (фактический RTO);
  • таймауты/ретраи/circuit breaker/bulkhead: корректны ли, не создают ли шторм повторов;
  • graceful degradation: функциональность при недоступности зависимости;
  • автомасштабирование: реагирует ли вовремя (HPA, CA);
  • Мониторинг и алерты: сработали ли, вовремя ли, понятны ли runbook;
  • Данные: отсутствие потерь (RPO), идемпотентность, консистентность после восстановления;
  • Безопасность: ограничения RBAC/NetworkPolicy при сбоях, реакция на компрометацию;
  • Людские процессы: эскалации, коммуникации, знание runbook;
  • Ёмкость: хватает ли запаса при потере N%.

Безопасность экспериментов

  • начинать в dev/staging, затем canary-срез продакшна (1–5% трафика/одна ячейка) в рабочее время, при наличии дежурных;
  • автоматические условия остановки (SLO burn, ошибки > порога), кнопка аварийной остановки, ограниченная длительность;
  • явные разрешения и календарь экспериментов, уведомления (чтобы не путать с реальными инцидентами);
  • не проверять то, что заведомо сломает (сначала тесты и статический анализ); эксперимент с гипотезой, а не случайное разрушение;
  • защита данных: не портить реальные данные клиентов, использовать тестовые/теневые наборы;
  • соответствие требованиям (регуляторика), согласование с бизнесом;
  • RBAC для инструмента хаоса (строго ограничить namespaces и действия), аудит запусков.

Внедрение и зрелость

УровеньПрактика
0нет экспериментов
1ручные эксперименты в dev/staging, game day раз в полгода
2автоматизированные эксперименты в CI/staging (после деплоя), регулярные game days
3эксперименты в проде в малом масштабе (canary), условия остановки по SLO
4непрерывный хаос как часть платформы (continuous verification), интеграция с SLO, автоматические регрессии устойчивости

Первые шаги: выбрать критичный сервис и самый вероятный сбой («падение одной реплики», «недоступен кэш», «задержка БД»), сформулировать гипотезу по SLI, провести на staging под нагрузкой, исправить найденное, автоматизировать. Результаты фиксировать в реестре (что проверили, что нашли, что исправили).

Связь с другими практиками

  • SRE/SLO: хаос проверяет, выдерживает ли система SLO при отказах; error budget определяет, когда можно экспериментировать;
  • HA и DR: проверка на практике (failover, восстановление);
  • Observability: без хороших метрик/логов/трейсов эксперименты бесполезны;
  • Incident Management: game days тренируют on-call;
  • Performance/load testing: совместно (нагрузка + сбой);
  • Security: red team/purple team — хаос для безопасности.

Частые находки

  • отсутствующие таймауты и бесконечные ретраи → каскад;
  • readiness/liveness не отражают реальность;
  • одна реплика «на всякий случай» или все реплики в одной зоне;
  • кэш упал → БД не выдержала (нет защиты/деградации);
  • секреты/сертификаты истекли без алертов;
  • runbook устарел, доступы отсутствуют, мониторинг «слеп» при отказе;
  • автомасштабирование слишком медленное, лимиты квот;
  • зависимость от единого DNS/реестра/CI/Vault;
  • неверные PodDisruptionBudget блокируют обновления.

Вопросы с ответами

Вид графа

Обратные ссылки