Chaos engineering — это эксперимент, а не разрушение
Цель практики — повысить уверенность, что система выдерживает реальные турбулентные условия. Principles of Chaos предлагает определить steady state, сформулировать гипотезу, внести реалистичный отказ и попытаться обнаружить различие между control и experiment.
Команда не «ломает production ради интереса». Она проверяет конкретное обещание с ограниченным воздействием и заранее подготовленным прекращением.
Почему ИИ-системе мало обычного pod kill
LLM-приложение зависит от внешней модели, quota, streaming, retrieval index, tools, approvals и durable state. Все pods могут быть живы, пока провайдер возвращает malformed JSON или модель выбирает другой tool после fallback.
Инфраструктурный chaos остаётся полезным, но сценарии должны доходить до пользовательского outcome и побочных эффектов агента.
Опишите steady state через результат
Используйте долю успешных задач, p95 TTFT и completion, valid output rate, cost per success, queue age и fallback rate. Для RAG добавьте citation correctness и freshness. Для write-agent — число эффектов на бизнес-операцию.
Снимите baseline на таком же сегменте до эксперимента. Если нормальное состояние неизвестно, после fault injection невозможно отличить дефект от обычного шума модели.
Safety invariants важнее среднего steady state
Cross-tenant leakage, действие без approval, раскрытие секрета и повторный платёж являются немедленным stop condition. Их нельзя компенсировать тем, что средняя latency осталась хорошей.
Проверяйте invariants детерминированными средствами: audit events, effect ledger, permission decisions и reconciliation, а не самооценкой модели.
Матрица отказов ИИ-системы
- Model: timeout, 429, 5xx, медленный stream, несовместимый output.
- RAG: пустой поиск, stale index, медленный reranker, отказ ACL.
- Tools: timeout до и после effect, malformed response, revoked permission.
- Workflow: duplicate delivery, lost heartbeat, stale checkpoint.
- Control plane: stale config, недоступный flag provider, ошибочный route.
- Telemetry: exporter тормозит или недоступен.
Приоритизируйте по частоте и потенциальному ущербу, а не по зрелищности.
Гипотеза должна быть опровержимой
Слабая формулировка: «сервис переживёт отказ модели». Сильная: «при 100% timeout primary в canary cohort не менее 97% read-only задач завершатся через fallback за 12 секунд, schema validity останется выше 99,5%, а cost вырастет не более чем вдвое».
Укажите длительность, cohort, fault, ожидаемые metrics и запрещённые события.
Начинайте с минимального blast radius
Первый запуск выполняйте в staging на production-like данных, затем на synthetic tenant или внутренней когорте. Ограничьте регион, одну capability, число задач, длительность и максимальный cost.
Principles of Chaos требует минимизировать fallout. Расширять blast radius можно только после подтверждённого recovery на предыдущем уровне.
Stop conditions и аварийная кнопка
AWS Fault Injection Service связывает stop condition с alarm и прекращает experiment при достижении порога. Для ИИ добавьте alarms на critical policy event, duplicate effect, burn rate, queue age, cost и human escalation.
Остановка fault injection не всегда мгновенно восстанавливает систему. Runbook должен закрыть circuit, вернуть route, дождаться drain и сверить неизвестные эффекты.
Эксперимент: неоднозначный timeout write-tool
Инжектор применяет тестовый effect, но скрывает ответ и возвращает timeout. Гипотеза: агент не повторит write, запросит статус по idempotency key и завершит ровно с одним effect.
Проверяйте ledger и внешнюю sandbox-систему. Финальный текст «готово» не является доказательством корректности.
Эксперимент: деградация RAG
Искусственно задержите retriever, удалите часть shards или подайте stale corpus version. Ожидаемая стратегия может быть safe abstention, cached answer с датой или передача человеку — но не уверенный ответ без evidence.
Измеряйте false answer, false abstain, freshness, latency и долю явно маркированной деградации.
Kubernetes PDB помогает, но не является щитом
PodDisruptionBudget ограничивает число одновременно недоступных replicas при добровольных evictions. Involuntary disruptions он не предотвращает, а прямое удаление некоторых ресурсов может обходить PDB.
Проверяйте и корректный drain через Eviction API, и жёсткую потерю node. Для stateful agent важен не только replacement pod, но и восстановление lease и checkpoint.
Наблюдаемость самого эксперимента
Каждый run получает experiment ID, hypothesis version, target cohort, fault start/end и control marker. Trace связывает injected fault с route, retries, tools и outcome.
Не полагайтесь на один dashboard: сохраните raw events и effect ledger для расследования. Telemetry outage также должен иметь сценарий, в котором data plane не блокируется exporter.
После эксперимента: recovery и доказательства
Завершение fault не означает восстановление. Измерьте time to steady state, опустошение очереди, закрытие circuits, возвращение canary route и reconciliation всех effect_unknown.
Если гипотеза опровергнута, это полезный результат: остановите повторение, назначьте owner и превратите слабость в regression test. Не запускайте более широкий experiment до исправления.
Чек-лист chaos-эксперимента
- Есть business owner и on-call.
- Steady state измерен до запуска.
- Гипотеза имеет численные пороги.
- Меняется один контролируемый фактор.
- Target cohort и blast radius ограничены.
- Safety invariants проверяются автоматически.
- Stop conditions активны и протестированы.
- Rollback и recovery runbook готовы.
- Experiment ID присутствует во всех traces.
- После остановки выполнена reconciliation.