Chaos Engineering: устойчивость систем

Chaos Engineering: устойчивость систем

1) Зачем хаос-инженерия

• проверить гипотезы о поведении системы и валидировать SLO;
• обнаружить скрытые SPOF, неверные таймауты/ретраи, каскадные эффекты;
• потренировать команды: game-days, отработка runbook’ов, коммуникаций;
• формировать культуру «устойчивость по умолчанию», а не «надеемся на лучшее».

Важно: Chaos Engineering ≠ «ломать все». Это научный метод: steady-state → гипотеза → эксперимент → выводы → улучшения.

2) Базовый цикл эксперимента

1. Steady-state (базовая линия): какие SLI стабильны? (например, успех ≤500 мс в 99.95%).
2. Гипотеза: при потере одной AZ p95 вырастет <10%, а доступность ≥99.9%.
3. Эксперимент: спланированный фолт с ограниченным blast radius и stop-критериями.
4. Наблюдение: метрики/трейсы/логи, burn-rate SLO, бизнес-SLI (например, успешные депозиты).
5. Улучшения: фиксируем находки, меняем таймауты/лимиты/маршрутизацию, обновляем runbook.
6. Автоматизация/регресс: повторяем в расписании, добавляем в CI/CD и календари game-days.

3) Перила безопасности (safety first)

Blast radius: начинаем с узкого — один pod/инстанс/маршрут/namespace.
Guardrails: алерты на SLO burn-rate (быстрый/медленный), лимиты ретраев, ограничение QPS, бюджет инцидента.
Stop-критерии: “если error-rate > X% или p99 > Y мс N минут — мгновенно stop и rollback”.
Окна: рабочие часы on-call, уведомленные стейкхолдеры, замороженные релизы.
Коммуникация: IC/Tech lead/Comms, четкий канал (War-room), шаблон сообщений.

4) Классы отказов и идеи гипотез

Сеть: задержка/джиттер/потери, частичный дроп портов, «флапающая» связь между сервисами/PSP.
Компьют/узлы: убийство процессов, перегрев CPU, исчерпание файловых дескрипторов, узкие пулы соединений.
Хранилища и БД: рост latency дисков, lag реплик, стоп одного шарда/лидера, split-brain.
Зависимости: деградация внешних API, лимиты провайдеров, 5xx/429 всплески.
Управление изменениями: неудачный релиз, плохой фича-флаг, partial rollout.
Периметр: CDN деградирует, DNS/Anycast дрифт, сбой WAF/бот-защиты.
Регион/AZ: полная потеря или «частичный» инцидент (чуть-чуть хуже и непредсказуемо).

5) Инструменты и техники

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Облака: AWS Fault Injection Simulator (FIS), Fault Domains у облаков.
Сеть/прокси: Toxiproxy (TCP-яд), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Процессы/узлы: `stress-ng`, cgroups/CPU-throttle, disk fill.
Трафик-маршрутизация: GSLB/DNS weights, canary/blue-green переключения для фейловер-проверок.

6) Примеры сценариев (Kubernetes)

6.1 Delay/abort на маршруте (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Гипотеза: клиентские таймауты/ретраи и CB удержат p95 < 300 мс и error-rate <0.5%.

6.2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Гипотеза: балансировщик и HPA компенсируют loss одного экземпляра без роста p99 > 20%.

6.3 Сетевой хаос (задержка к БД)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Гипотеза: пулы/таймауты/кэш снизят влияние; p95 платежей останется ≤ SLO.

6.4 Заполнение диска

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

Гипотеза: ротация логов/квоты/алерты сработают до деградации маршрутов.

7) Эксперименты вне K8s

7.1 Toxiproxy (локальный/интеграционный)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7.2 Envoy HTTP fault (периметр/mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7.3 AWS FIS (пример идеи)

Эксперимент «убить» N% EC2 в Auto Scaling Group, искусственно поднять EBS-latency, отключить NAT-GW в одной AZ.
Встроенные стоп-критерии по CloudWatch SLO-метрикам.

8) Метрики наблюдаемости во время хаоса

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
RED-модель по критичным маршрутам (Rate, Errors, Duration).
Пулы: ожидание соединения p95, utilization.
БД: lag реплик, locks, дрейф p95 запросов.
Сеть: retransmits, RTT, dscp/ecn поведение.
Бизнес-SLI: успех транзакций (депозиты/чекаут), % возвратов/ошибок.
Трассировка: выборочные трейсы (exemplars), корреляция релиз-аннотаций.

9) Интеграция с SLO/Error-budget

Планируйте эксперименты в рамках бюджета ошибок: хаос не должен «срывать» квартальные цели.
Burn-rate алерты как автоматические kill-switch.
Отчетность: «сколько бюджета сожгли», «какие девиации steady-state».

10) Game-days (учения)

Сценарий: краткая легенда (например, «регион-East потерян»), шаги инъекций, цели SLO, роли, время.
Оценка: RTO/RPO фактические, качество коммуникаций, корректность runbook.
Ретро: список улучшений с владельцами и сроками, обновление документации/дашбордов.

11) Автоматизация и CI/CD

Smoke-chaos: короткие тесты на staging при каждом релизе (например, 1 pod-kill + 200 мс delay на один маршрут).
Ночные/еженедельные: более тяжелые сценарии (5–15 мин) с отчетом.
Промо-гейты: если p95/ошибки > порога на canary — авто-откат.
Репозитории с каталогом экспериментов (YAML + runbook + SLO-thresholds).

12) Анти-паттерны

«Ломать прод без перил»: нет stop-критериев, нет on-call → риск настоящего инцидента.
Одноразовая акция вместо процесса.
Хаос без steady-state: непонятно, что считать успехом/провалом.
Избыточные ретраи → само-DDoS при инъекции задержек.
Игнорирование бизнес-SLI: «технарские» успехи при провале платежей/заказов.
Отсутствие пост-анализа и владельцев улучшений.

13) Чек-лист внедрения (0–45 дней)

0–10 дней

Определить steady-state SLI (пользовательский + бизнес).
Выбрать инструмент (Chaos Mesh/Litmus/Toxiproxy/FIS).
Описать перила: blast radius, stop-критерии, окна, роли.

11–25 дней

Запустить первые эксперименты: pod-kill, 100–200 мс delay на критичный апстрим, drop 1% пакетов.
Настроить burn-rate алерты, связать kill-switch со stop-критериями.
Провести первый game-day, собрать ретро и фиксы.

26–45 дней

Добавить сценарии уровня AZ/зависимостей (внешний PSP, БД-lag).
Автоматизировать nightly-хаос на staging; готовить «сезонные» сценарии (пики).
Каталог экспериментов и регулярные отчеты для руководства/SRE.

14) Метрики зрелости

≥80% критичных маршрутов имеют описанные эксперименты и steady-state метрики.
Авто kill-switch срабатывает при превышении порогов p99/error-rate.
Ежеквартально — game-day уровня AZ/регион; ≥1 раз/мес — целевой сценарий зависимостей.
MTTR снижается после цикла улучшений, корреляция «релиз ↔ инцидент» уменьшается.
Доля «неожиданных» падений при реальных сбоях → стремится к нулю.
Дашборды показывают «устойчивость» как KPI (burn-rate, время восстановления, доля успешных DR-действий).

15) Примеры guardrails и триггеров stop

Stop при: `http_req_failed > 1%` 3 минуты, `p99 > 1000 мс` 3 окна, `deposit_success < 99.5%`.
Снижение blast radius: авто-откат манифеста, возврат весов GSLB, отключение fault-инъекций.
Команда stop: единая кнопка/скрипт с логированием причин.

16) Культура и процессы

Хаос — это часть SRE-ритма, не «экстрим».
Прозрачные отчеты, признание уязвимостей, корректирующие действия.
Обучение on-call, симуляции коммуникаций с клиентами/партнерами.
Увязка с SLA/SLO и бюджетами: хаос должен повышать, а не подрывать надежность.

17) Заключение

Chaos Engineering превращает «надежду на девятки» в доказуемую устойчивость. Формулируйте steady-state, ставьте перила, ломайте малое и контролируемое, наблюдайте SLO и бизнес-SLI, фиксируйте и автоматизируйте улучшения. Тогда реальные сбои станут управляемыми событиями: предсказуемый RTO, защищенный error-budget и готовность команды действовать без паники.