Хаос-тестирование перестало быть экзотикой: всё больше команд хотят проверять устойчивость систем не только на стейджах, но и в реальном продакшене. Однако просто «уронить под» недостаточно — нужен управляемый процесс, который не разрушит сервис, а даст полезные данные. В этой статье разберём, как подойти к хаос-тестированию осознанно, какие инструменты выбрать, как встроить LLM и не наступить на типичные грабли. Опираемся на опыт команды TestOps из PaaS Авито, но без привязки к конкретным внутренним решениям — только практические шаги.

Зачем вообще внедрять сбои в продакшене

Главная цель хаос-тестирования — выявить слабые места системы до того, как они проявятся в реальной аварии. На стейджах невозможно воспроизвести все сочетания нагрузок, сетевых задержек и отказов инфраструктуры. Продакшен даёт реалистичную картину, но требует осторожности. Хаос-эксперименты помогают ответить на вопросы: выдержит ли сервис потерю узла? Как поведёт себя система при деградации сети? Сработают ли алерты и автоматическое восстановление? Без таких проверок команда узнаёт о проблемах только из инцидентов, что дороже и рискованнее.

Шаг 1: определите границы и метрики

Прежде чем что-то ломать, зафиксируйте, что именно вы проверяете и по каким признакам поймёте, что эксперимент прошёл успешно. Начните с инвентаризации: какие сервисы критичны, какие можно затронуть без ущерба для пользователей, какие есть механизмы изоляции (например, канареечные релизы или теневой трафик). Определите целевые метрики: время восстановления, доля ошибок, задержки, срабатывание алертов. Без чётких критериев хаос-тестирование превращается в бесполезное развлечение.

  • Выделите ограниченный периметр — например, один кластер или группу подов, не затрагивая критичные пользовательские сценарии.
  • Согласуйте эксперимент с on-call и смежными командами, чтобы не создать ложную аварию.
  • Задайте пороги остановки: если ошибки превышают допустимый уровень, эксперимент немедленно прекращается.

Шаг 2: выберите инструменты и оркестратор

Рынок предлагает готовые решения: Chaos Mesh, Litmus, Gremlin, AWS Fault Injection Simulator. Они покрывают базовые сценарии — отказ подов, задержки сети, заполнение диска. Однако в крупных компаниях часто возникает потребность в собственном оркестраторе, который учитывает внутреннюю специфику: интеграцию с системами деплоя, кастомные проверки, сбор результатов. Критерии выбора простые: инструмент должен поддерживать нужные типы сбоев, иметь API для автоматизации, обеспечивать безопасность (например, автоматическую отмену при выходе за пороги) и вписываться в ваш стек мониторинга.

Если готового решения не хватает, не спешите писать всё с нуля. Начните с открытых фреймворков и добавьте недостающие обвязки: планировщик, систему approvals, дашборды. Собственный оркестратор оправдан, когда эксперименты становятся регулярными и требуют сложной логики согласования.

Шаг 3: встройте LLM в анализ экспериментов

LLM не должна управлять хаосом напрямую — это рискованно. Её разумное применение — помогать инженерам анализировать результаты и прошлые инциденты. Например, можно автоматически суммировать логи эксперимента, выделять аномалии и предлагать гипотезы о причинах. В Авито LLM используют для разбора прошлых инцидентов (LSR) и генерации выводов по конкретным экспериментам (AI-conclusion). Это снижает рутину и ускоряет принятие решений, но требует проверки: модель может ошибаться или галлюцинировать.

  • Ограничьте роль LLM — только анализ и рекомендации, без автоматического запуска сбоев.
  • Обеспечьте прозрачность: каждый вывод модели должен сопровождаться ссылками на исходные данные (логи, метрики).
  • Валидируйте результаты — привлекайте инженеров для проверки критичных выводов.

Типичная ошибка — пытаться заменить LLM эксперта. Модель хорошо справляется с рутинной агрегацией, но окончательное решение остаётся за человеком.

Типичные ошибки и как их избежать

Даже опытные команды допускают промахи. Вот несколько распространённых:

  • Запуск хаоса без предупреждения — приводит к панике on-call и ложным инцидентам. Всегда согласуйте эксперимент.
  • Отсутствие «стоп-крана» — если сбой вышел из-под контроля, нужен автоматический механизм отмены. Например, при превышении уровня ошибок эксперимент должен останавливаться.
  • Игнорирование результатов — если после эксперимента не проводится разбор и не создаются задачи на исправление, смысл теряется.
  • Слишком широкий охват — начинайте с малого: один сервис, один тип сбоя, минимальное время. Постепенно расширяйте периметр.

Пример из практики: команда запустила отказ всех подов в кластере, не проверив, что автоскейлер не успеет поднять новые. В итоге пользователи столкнулись с недоступностью. Чтобы избежать такого, всегда моделируйте сценарий на стейдже и проверяйте реакции инфраструктуры.

Что в итоге

Хаос-тестирование — это не про безрассудное разрушение, а про контролируемый эксперимент. Начните с чётких границ и метрик, выберите инструменты под задачи, подключите LLM для анализа, но оставьте человеку право последнего слова. И помните: главная ценность — не сам факт сбоя, а знания, которые вы получаете, и исправления, которые за ними следуют.