Что такое chaos engineering

Chaos engineering — дисциплина, цель которой — заранее проверять, как система ведёт себя при реальных отказах, путём контролируемого внедрения сбоев. Идея: не ждать прод-аварии, а систематически находить слабые места и повышать устойчивость.

Основные принципы

1. Эксперимент, а не хаос — каждое вмешательство должно иметь гипотезу: что произойдёт со «steady state» (метриками) при данном сбое.

2. Наблюдаемость — до эксперимента нужны метрики/логи/трейсы; без этого тест бесполезен.

3. Контролируемый blast radius — начинать с малого и постепенно расширять влияние.

4. Повторяемость и автоматизация — тесты должны выполняться регулярно и воспроизводимо.

5. Blameless практика — ошибки — повод для улучшения процессов и автоматизации.

Пошаговый процесс проведения эксперимента

1. Определите steady state — ключевые SLI/SLO и бизнес-метрики (latency p95, error rate, транзакции, throughput).

2. Сформулируйте гипотезу — например: «При потерях пакетов 5% p95 latency увеличится менее чем на 20% и 5xx не превысит 0.5%».

3. Выберите сценарий и ограничьте blast radius — один pod, одна AZ, 1% трафика, internal users only.

4. Подготовка и safety — включите kill-switch/автоматический откат, окно maintenance, уведомите on-call и стейкхолдеров, сделайте бэкап критичных данных.

5. Запустите эксперимент — внедряйте сбой (например, задержки сети, убить pod, нагрузка CPU).

6. Наблюдайте и записывайте — метрики, логи, трассы, бизнес-метрики. Сравнивайте с expected.

7. Закончите и восстановитесь — автоматически или вручную откатите эксперимент.

8. Анализ и действия — postmortem: подтвердить/опровергнуть гипотезу, назначить remediation (automation, alert tuning, архитектурные изменения).

9. Автоматизируйте — добавьте успешные сценарии в регулярный прогон (pipeline).

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

• инстанс-kill (удаление pod/VM),

• network fault (latency, packet loss, partition),

• overload (CPU/RAM/Disk IO),

• dependency failure (DB down, external API 500),

• resource exhaustion (connection pool saturation),

• graceful degradation (simulate high load and check fallback),

• chaos направленный на deployments (попытка отката/невозможность deploy).

Инструменты

Gremlin, Chaos Mesh, LitmusChaos, Pumba, Chaos Monkey, kubernetes-chaos-tools, доп. — собственные скрипты + orchestration через CI/CD.

Метрики и критерии успеха

SLI (availability, latency p95/p99), error rate, throughput, queue depth, DB replication lag, business KPIs (checkout rate). Устанавливайте критерии «acceptance»: допустимое ухудшение и допустимое время восстановления.

Безопасность и guardrails

• заранее тестировать в staging;

• иметь простой «abort» (kill switch) и время ожидания before-escalation;

• не тестировать критичные операции (финансовые транзакции) без сильных гарантий;

• юридические/регуляторные ограничения учитывать обязательно;

• проводить эксперименты в заранее согласованные окна.

Организация и культура

Проводите регулярные GameDays, включайте продукт и SRE, документируйте результаты, переводите результаты в автоматизацию (runbooks, self-heal) и в CI.

Шаблон эксперимента (коротко)

• Цель: …

• Steady state: …

• Гипотеза: …

• Сценарий: … (что именно ломаем)

• Blast radius: …

• Safety: kill-switch, owner, окно

• Метрики для наблюдения: …

• Результат и action items: …

Планомерная, безопасная практика chaos engineering помогает обнаруживать скрытые зависимости, улучшать автоматизацию восстановления и снижать MTTR до того, как случится настоящая катастрофа.