Synthetic Incident Drills в 2026: как репетировать поломки agent stack до реального инцидента
Synthetic incident drills в 2026 нужны потому, что agent stack редко ломается красиво и предсказуемо. На практике инцидент может начаться не с полного outage, а с ростa retries, смены route behavior, падения citation quality, repeated tool mismatch или слишком позднего human escalation. Если команда не репетировала такие сценарии заранее, runbooks и kill switches обычно оказываются непропорционально слабыми в реальной ситуации.
1. Drill нужен для проверки не модели, а системы реагирования
Главный вопрос drills звучит не "может ли агент ошибиться?" — это и так известно. Более полезные вопросы:
- заметим ли мы ошибку вовремя;
- сможем ли ограничить blast radius;
- сохраним ли нужные артефакты;
- не сломаем ли при containment полсервиса;
- умеем ли восстановиться без повторного инцидента.
2. Какие сценарии особенно полезны
Provider degradation
- latency spike;
- partial outage;
- schema drift;
- fallback activation.
Tool-layer incident
- repeated timeouts;
- stale result injection;
- wrong-tool burst;
- external API mismatch.
Review-layer incident
- queue overload;
- approval service unavailable;
- escalation backlog.
RAG/trust incident
- poisoned retrieval;
- stale policy doc;
- missing provenance.
Agent runaway
- repeated loops;
- duplicate side effects;
- browser task stuck in retry cycle.
3. Drills полезно проводить на runbook boundaries
Хороший drill проверяет:
- кто получает alert;
- кто owner containment;
- где находится kill switch;
- кто подтверждает degraded mode;
- как сохраняются traces and artifacts;
- как команда решает, что recovery уже безопасен.
Это делает drill не просто technical exercise, а проверкой operational coordination.
4. Shadow and synthetic можно комбинировать
Например:
- synthetic outage в staging;
- shadow comparison в production;
- replay проблемных traces;
- review queue simulation.
Так можно проверить и technical mechanics, и human response, не создавая лишний риск на живом трафике.
5. Что особенно часто ломают команды
Drill as theater
Команда формально проходит сценарий, но без реальных triggers и evidence capture.
No artifact verification
После drill никто не проверяет, что traces, screenshots и state snapshots правда сохранились.
Only one dramatic outage scenario
Частичные degradations не репетируются.
No timing analysis
Команда не меряет time-to-detect и time-to-contain.
No follow-up changes
После drill runbook не меняется.
6. Какие метрики полезны
Минимальный drill dashboard обычно включает:
- time-to-detect;
- time-to-contain;
- percent of required artifacts captured;
- fallback activation quality;
- kill-switch targeting accuracy;
- number of runbook changes after drill.
Плюсы
- Drills превращают runbooks из текста в проверенный operational механизм
- Помогают находить слабые alerts и грубые kill switches до реального инцидента
- Проверяют связку технического и human response
- Снижают surprise factor во время настоящих сбоев
Минусы
- Требуют времени и coordination
- Слишком поверхностные drills быстро становятся формальностью
- Непродуманные drill-сценарии могут мешать команде, не давая полезного сигнала
- Нужна дисциплина по follow-up, иначе эффект быстро исчезает