Chaos Engineering

Август 2008: три дня Netflix лежит из-за коррапта базы в дата-центре, не может рассылать DVD. Вывод: дата-центры падают, инфраструктура должна сама переживать сбои. Netflix начинает миграцию в AWS, к 2010-му создаёт Chaos Monkey, в июле 2011-го анонсирует Simian Army, в 2012-м открывает код. Инструмент случайно убивает production-инстансы. Не в staging, не в QA - в проде, среди рабочего дня. Реакция индустрии: 'они сумасшедшие'. Результат: Netflix стал эталоном reliability в cloud-native архитектуре. Simian Army - целый зоопарк chaos-инструментов. Принцип: лучше намеренно вызывать сбои и учиться, чем ждать незапланированных инцидентов.

• **Netflix Simian Army**: Chaos Monkey (убивает инстансы), Chaos Kong (убивает availability zone), Latency Monkey (добавляет задержки), Conformity Monkey (проверяет best practices)
• **Amazon Prime Day**: ежегодно проводятся Game Days за несколько месяцев до события. Симулируются пиковые нагрузки, отказы зависимостей, потеря регионов - чтобы Prime Day не стал настоящим инцидентом
• **Facebook Codepath**: автоматический fault injection при каждом деплое в staging. Если сервис не переживает падение зависимости - деплой не проходит. Chaos как gate в CI/CD

Chaos Monkey

Chaos Monkey - инструмент созданный Netflix в 2011 году во время миграции в AWS. Случайно убивает production инстансы в рабочее время. Идея: если система упадёт ночью от отказа инстанса - это катастрофа. Если она падает днём при разработчиках - это учебная тревога. Лучше намеренно вызывать сбои и учиться справляться с ними, чем ждать непредвиденных инцидентов.

Принципы Chaos Engineering (Netflix): строить гипотезу о поведении системы в steady state, затем вызывать turbulence (отказы), наблюдать отклонение от steady state, итерировать. Ключевое: Chaos Engineering не про намеренное разрушение - это controlled experiments для обнаружения слабых мест до того как это сделает реальный инцидент. Начинать с минимальным радиусом поражения: один инстанс, не availability zone.

Fault Injection

Fault Injection - намеренное введение ошибок в систему для тестирования реакции. Типы фолтов: Resource Exhaustion (исчерпание памяти, CPU, disk), Network Faults (задержки, packet loss, partition), Dependency Failures (убить dependency сервис), Time Faults (clock skew, leap seconds), State Corruption (битые данные в cache или DB). Каждый тип проверяет разные аспекты resilience.

Инструменты: Chaos Toolkit (open source, YAML-описания экспериментов), AWS Fault Injection Simulator (managed service), Gremlin (enterprise), Istio Fault Injection (network level через VirtualService). Litmus Chaos для Kubernetes: CRD-описания экспериментов, интеграция с CI/CD. Facebook Codepath: автоматический fault injection при каждом деплое в staging - если сервис не обрабатывает зависимость которая упала, деплой блокируется.

Game Days

Game Day - запланированное событие где команда намеренно создаёт реалистичные failure сценарии и тренируется их обрабатывать. Amazon использует Game Days для подготовки к Prime Day и Black Friday: команды симулируют потерю availability zone, всплеск трафика в 10x, отказ критических зависимостей. После Game Day: выявленные слабые места, тренированные инженеры, обновлённые runbooks.

DiRT (Disaster Recovery Testing) у Google: ежегодные тесты disaster recovery сценариев. Целая команда уходит в 'отпуск' симулируя недоступность. Остальные должны поддерживать критические сервисы без помощи этой команды. Это проверяет документацию, runbooks, bus factor (что будет если ключевой человек недоступен?). Netflix GameDay: четыре типа сценариев - People, Process, Systems, Environment.

Resilience Patterns

Resilience (устойчивость) - способность системы продолжать работать при частичных отказах. Graceful Degradation: при недоступности рекомендаций - показывать популярные товары. При проблемах с поиском - базовый каталог. Пользователь получает ухудшенный, но работающий сервис. Amazon.com: если рекомендательный движок падает - страница загружается без рекомендаций, не с ошибкой.

Bulkhead - изоляция ресурсов для предотвращения cascade failures. Аналог переборок корабля: проблема в одном отсеке не топит всё судно. В микросервисах: отдельный thread pool для каждой зависимости (Hystrix Bulkhead). Если payment thread pool исчерпан - не затрагивает catalog thread pool. Timeout + Retry с exponential backoff: первый retry через 1 сек, второй через 2 сек, третий через 4 сек - предотвращает thundering herd при восстановлении.

Связанные темы

Chaos Engineering работает вместе с другими reliability практиками:

• SRE: Site Reliability Engineering — Error budget: chaos experiments расходуют error budget, но создают resilience. SLO определяет приемлемый уровень chaos
• Observability: логи, метрики, трейсы — Без хорошей observability chaos experiments бессмысленны - невозможно наблюдать реакцию системы на fault injection

Вопросы для размышления

• С чего начать внедрение Chaos Engineering в команде которая никогда этим не занималась - и как убедить менеджмент?
• Chaos в production vs chaos в staging: какие сценарии можно безопасно тестировать только в staging?
• Как определить что система достаточно resilient - и нужна ли абсолютная устойчивость ко всем возможным отказам?

Связанные уроки

• sd-03-scalability