Авито связал LLM с хаос-тестами и увеличил покрытие инцидентов с 22% до 41%

Инцидент закончился, команда написала разбор, завела задачи — и через квартал получила почти такой же сбой. Знакомая история: продуктовые фичи постоянно обгоняют технический долг, а выводы из post-mortem постепенно превращаются в архив.

В Авито попробовали замкнуть этот разрыв. Прошлые аварии стали источником сценариев для хаос-тестов, а LLM — фильтром, который помогает разбирать сотни отчётов. Модель изучила 977 LSR, оценила, какие сбои можно воспроизвести, и предложила подходящие аномалии. Затем инженер проверяет, действительно ли тест повторяет первопричину, а не просто создаёт похожую картинку на графиках.

От отчёта об аварии к проверке в проде

Пайплайн обогащал текст LSR перепиской из связанного чата, а затем задавал модели шесть отдельных вопросов. Она кратко описывала причину и симптом, оценивала возможность хаос-теста, проверяла судьбу Action Items, выставляла сценарию балл от 0 до 10 и подбирала аномалии из внутренней библиотеки. Результаты сохранялись в MongoDB, а в Elasticsearch строился векторный индекс для поиска похожих инцидентов.

Так Авито получило 432 автоматически обновляемых вывода для 408 сервисов. По оценке модели, 41% разобранных аварий можно воспроизвести существующими или запланированными средствами. Для одного LitmusChaos, работающего главным образом на уровне подов, показатель составлял около 22%. Доменный оркестратор Kratos почти удвоил потенциальное покрытие за счёт сценариев для баз данных и сети.

Простой пример — переключение мастера Redis. Обычный тест может завершить процесс или удалить под, но это не то же самое, что реальные перевыборы primary внутри репликасета. Поэтому команда добавила сценарий trigger-primary-re-election для MongoDB и Redis. Именно он используется в 95,6% автоматических прогонов: сервисы проверяют на настоящем переключении мастера, а не на приблизительной имитации.

Где LLM ошибается

Высокий балл модели ещё не означает полезный тест. В одном случае причиной аварии была неправильная конфигурация Nginx после исправления уязвимости. LLM дала сценарию 10 из 10 и предложила сетевую задержку. Симптомы действительно были похожи: ошибки HTTP, тайм-ауты и недоступные документы. Но хаос-тест не мог изменить конфигурацию сторонней системы и потому никогда не воспроизвёл бы первопричину.

Это важное ограничение. Модель хорошо сортирует большой массив отчётов и подсказывает инженеру, куда смотреть, но способна спутать причину со следствием. Авито не передаёт ей окончательное решение: человек проверяет гипотезу, область воздействия и безопасность запуска. Сам пайплайн анализа сейчас приостановлен после закрытия внутреннего сервиса с прежней моделью, хотя накопленный датасет и методика сохранились.

Что можно забрать себе

Начинать стоит не с покупки хаос-платформы, а с карты реальных сбоев. Разделите их на ресурсы, сеть, процессы, прикладной уровень, внешнюю инфраструктуру и бизнес-логику. Затем сопоставьте каждому классу проверяемую первопричину, безопасное окно и измеримый критерий восстановления.

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