ИИ анализирует журналы инцидента: как проверить вывод по событиям

Исходные события важнее красивой истории

Каждая запись должна сохранять время с зоной, источник, идентификатор запроса и исходный текст. Если часы сервисов расходятся, отметьте это до построения хронологии. Попросите ИИ разделить наблюдаемые факты и гипотезы: «ошибка начала появляться после релиза» — наблюдение, «релиз её вызвал» — предположение, требующее проверки.

Не загружайте в неподходящий сервис секреты, токены и персональные данные из журналов. Подготовьте выборку с сохранёнными связями между событиями, но без лишних чувствительных полей.

Что поручить модели

Она может сгруппировать похожие сообщения, найти первое появление нового типа ошибки и показать пробелы в хронологии. Для каждой гипотезы нужен путь к исходным строкам. Если система не может сослаться на событие, её вывод не должен становиться основанием для отката или внешнего сообщения клиентам.

Проверка на старых инцидентах

Возьмите завершённые случаи с известной причиной и дайте модели только данные, доступные в первые минуты. Смотрите, помогает ли она быстрее найти нужный источник или уверенно увлекает команду неверной версией. По NIST AI RMF оценка должна учитывать последствия использования; для инцидента это время восстановления и риск ошибочного действия, а не литературное качество отчёта.

Пример ложной причинности

В 10:05 выпустили новую версию, а в 10:07 выросли ошибки. Модель пишет: «релиз вызвал сбой». Инженер видит, что в 10:04 начал отвечать с ошибками внешний сервис, а метрики новой версии касаются другого маршрута. В отчёте полезно разделить события по времени и компонентам, затем назвать гипотезы для проверки. Само соседство событий не доказывает причину, особенно когда журналы собираются с задержкой.

Что должно быть в кратком отчёте смене

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

После восстановления

Сравните предложенные агентом гипотезы с реальной причиной и отметьте, какие подсказки помогли, а какие отвлекли. Добавьте случай в тестовый набор с данными, которые были доступны в тот момент, а не с финальным отчётом задним числом. Иначе система покажется умнее, чем была во время инцидента.

Запрос к помощнику без готового ответа

Полезное задание звучит так: «Собери хронологию подтверждённых событий, сгруппируй одинаковые ошибки и перечисли гипотезы отдельно, указав исходные строки. Не называй причину доказанной». Это дисциплинирует результат, но технические права всё равно важны: модель не должна сама отключать сервис или отправлять сообщение клиентам. Инженер проверяет трассировки и выбирает действие по собственному плану инцидента.

Не теряйте отрицательные проверки

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