Смена парадигмы: от ручных разборов к постоянному стресс-тестированию
Классический путь работы с инцидентами в продуктовых командах часто ходит по кругу: сбой в продакшене сменяется разбором полетов (post-mortem), формируется перечень задач по исправлению, но из-за приоритета продуктовых фичей доработки зависают в бэклоге — до следующей аварии. Чтобы переломить эту практику, в Авито перешли к проактивному хаос-тестированию, проверяя сервисы на устойчивость прямо под боевой нагрузкой.
Для решения задачи команда PaaS развернула инфраструктуру «хаоса как сервиса», подключив к процессу искусственный интеллект: LLM анализирует исторические аварии, а специализированный агент связывает аномалии в метриках с дефектами в кодовой базе.
Почему открытых инструментов оказалось недостаточно
Базовым движком для внедрения сбоев стал популярный Kubernetes-оператор LitmusChaos. Однако в изоляции он умеет манипулировать только подами и контейнерами: убивать процессы, нагружать процессор или отсекать сеть. По статистике внутренних инцидентов компании, коробочные возможности Litmus закрывают лишь порядка 22% реальных сценариев поломок.
Инструмент не понимал логику баз данных — к примеру, он не мог штатно инициировать смену мастера в репликасетах Redis или MongoDB. Для преодоления этих ограничений инженеры разработали собственный оркестратор Kratos на языке Go. Тандем Litmus и Kratos позволил почти вдвое поднять охват воспроизводимости реальных сбоев — до 41% (более 400 кейсов из выборки в 977 инцидентов).
Как нейросеть исследует инциденты и читает репозитории
Искусственный интеллект в системе задействован на двух принципиальных этапах:
- Ретроспективный анализ инцидентов: Модель изучила 977 прошлых отчетов (LSR), оценивая потенциал воспроизведения сбоя через контролируемый стресс-тест. Это помогло автоматически приоритизировать сценарии: абсолютным лидером стал тест на перевыборы мастера баз данных (
trigger-primary-re-election). - AI-заключения по итогам тестов: Когда эксперимент завершается неудачно, AI-агент получает профиль прогона, метрики деградации и доступ к репозиторию сервиса. Нейросеть сопоставляет симптомы с исходным кодом и выдает конкретный вердикт — например, указывает на отсутствие джиттера в ретраях или некорректную обработку ошибок кэша с ссылками на конкретные файлы и строки.
Точность выводов подтверждается на практике: за последний период владельцы сервисов согласились с 87% заключений агента (61 случай согласия против 9 возражений), а десятки найденных проблем сразу ушли в работу.
Реальность продакшена: статистика и неожиданный барьер
Автоматический раннер запускает тесты в наименее нагруженные ночные часы после снятия базовых метрик и оценки рисков. Накопленная статистика показывает следующие результаты:
- Завершено 1129 полноценных испытаний на живой инфраструктуре (95,6% пришлось на смену мастера хранилищ).
- 79% прогонов получили оценки «отлично» и «хорошо» — зависимые системы штатно перенесли отказы узлов.
- Зафиксировано 89 эскалаций по деградации параметров на 64 сервисах.
- Влияние на бюджет ошибок (error budget) оказалось минимальным: медианный показатель расхода составил всего 0,14% в месяц на сервис.
Интересно, что главным сдерживающим фактором масштабирования стали не технические лимиты безопасности, а человеческий фактор. Система выполняет около 6 экспериментов в сутки вместо проектных 44: ключевое замедление вызывает необходимость получения явного согласия от владельцев систем на включение сервиса в автоматический контур.
Итоги внедрения
Практика показала устойчивую динамику: число сервисов, не выдерживающих потерю первичной реплики базы данных, сократилось со 141 исторического случая до единичных 8 систем на текущий момент. В ближайших планах команды — расширение проверок на этап канареечных релизов и реализация механизмов самовосстановления зависших сервисов.