Когда инцидент начинается в 3 часа ночи, первым вопросом редко бывает: «Можем ли мы выполнить поиск в нашей базе данных?» Обычно это что-то вроде: «Происходило ли это раньше, и могу ли я доверять тому, что сделал предыдущий ответчик?» Это различие сформировало мое мнение о нашем агенте по реагированию на инциденты.
Проект создан вокруг простой проблемы: история происшествий ценна, но одной исторической информации недостаточно.
Отвечающему нужен полезный прецедент, некоторое объяснение того, почему этот прецедент важен, и указание на то, был ли связанный модуль Runbook действительно успешным ранее.
Наша реализация решает эту проблему без внешнего LLM или зависимости от сети.
Приложение запускается локально с использованием FastAPI, SQLAlchemy, SQLite, реализации TF-IDF от scikit-learn и стандартного интерфейса JavaScript.
Результат меньше похож на просьбу ИИ изобрести решение, а больше на предоставление дежурному инженеру структурированной памяти о предыдущих инцидентах.
Проблема с обычной историей инцидентов.
Представьте, что API платежей начинает возвращать ошибки 502.
Инженер мог бы просмотреть старые записи об инцидентах и, возможно, найти что-то подобное.
Но «похожий» может означать несколько разных вещей.
Возможно, старый инцидент затронул тот же сервис.
Возможно, у него была та же подпись ошибки.
Возможно, это произошло в той же степени тяжести.
Возможно, в описании есть похожие слова.
Или, возможно, инцидент достаточно старый, и соответствующему Runbook больше нельзя доверять без проверки.
Простой поиск по ключевым словам не дает всего этого.
Вот почему наша система не возвращает только один непрозрачный процент сходства.
Он создает отпечаток инцидента с пятью измерениями: сходство текста, совпадение службы, ошибка, совпадение сигнатуры, серьезность совпадения, давность совпадения.
Это делает результат более полезным для человека, отвечающего на вызов, поскольку система раскрывает некоторые причины, лежащие в основе его совпадения.
Следование рабочему процессу ответчика Рабочий процесс приложения отражает то, что на самом деле делает инженер во время инцидента.
Сначала создается новый инцидент с такой информацией, как его описание, услуга, серьезность и сигнатура ошибки.
Затем конечная точка поиска сравнивает инцидент с разрешенными инцидентами: совпадения = сходство. find_similar_incidents ( query_text = f " { payload .description } " , query_service = payload . service , query_severity = payload . серьезность , query_error_sig = payload . error_signature , кандидатов = кандидатов, top_k = payload . top_k , ) Важная деталь здесь заключается в том, что система не ищет каждую запись без разбора.
Поисковый маршрутизатор извлекает инциденты со статусом РЕШЕНО, а затем отправляет этих кандидатов в механизм сходства.
Для респондента это создает гораздо более сфокусированный вопрос: какие решенные инциденты похожи на тот, с которым я сейчас имею дело?
Конкретный пример.
В тестах репозитория используется инцидент с платежами, включающий: 502-upstream-timeout.
Тестовый запрос описывает платежный API, возвращающий ошибки восходящего потока 502, в то время как пул соединений кажется насыщенным.
Исторический кандидат содержит ту же самую службу и сигнатуру ошибки.
Тест на сходство явно проверяет, что этот инцидент занимает первое место и что обнаружены совпадения как службы, так и сигнатур ошибок.
Это важно, поскольку демонстрирует реальное поведение реализации, а не гипотетический пример.
Ответ также несет в себе отпечаток пальца.
Вместо того, чтобы видеть что-то вроде: Совпадение: 87%, респондент может видеть такие доказательства, как: та же услуга, идентичная сигнатура ошибки, тот же класс серьезности, исторический заголовок инцидента, текстовая схожесть, недавность.
Поисковый маршрутизатор даже создает удобочитаемое объяснение:Why = " Соответствует " + " , " . join (Why_bits) + «.» Этот небольшой выбор дизайна важен.
Во время инцидента рекомендация, которая не может объяснить сама себя, порождает у инженера еще один вопрос: почему я должен этому доверять?
Объяснимое совпадение, по крайней мере, дает респонденту что-то конкретное для проверки.
Память – это больше, чем просто хранение событий.