Проблема: потеря организационной памяти во время инцидентов
Когда критически важный сервис выходит из строя в два часа ночи, самым ценным ресурсом для дежурного инженера становится организационная память. Возникают вопросы: случалась ли подобная блокировка базы данных раньше? Помогал ли перезапуск рабочих подов при всплеске задержек? На практике отчёты о вскрытии причин (postmortems) часто просто архивируются в вики и редко просматриваются во время активного инцидента. Инженеры вынуждены полагаться на собственную память и часто повторяют те же действия по устранению, которые уже оказывались неэффективными в прошлом.
Решение RecallOps: ассистент с постоянной памятью
Большинство инструментов для операций с поддержкой ИИ рассматривают каждый инцидент изолированно, начиная расследование с чистого листа, без связи с прошлыми уроками. Для решения этой проблемы был разработан RecallOps — система, которая сохраняет решения по инцидентам, вспоминает их в реальном времени и обеспечивает безопасные рамки, чтобы инженеры не путали непроверенные аналогии с доказавшими свою эффективность исправлениями.
Архитектура и ключевые компоненты
В основе RecallOps лежит идея постоянной памяти для операционных процессов. Для этого был интегрирован Hindsight — open-source движок долговременной памяти для ИИ-агентов. Эффективная операционная память требует чёткого разделения между общими знаниями, фактическими наблюдениями и конкретным операционным опытом.
Система состоит из нескольких ключевых модулей:
- Приём и локальное хранение: бэкенд на FastAPI с базой данных SQLite, который хранит записи об инцидентах, диагностические логи и подтверждённые инженерами результаты.
- Детерминированный движок анализа: основанный на правилах экстрактор симптомов и классификатор релевантности памяти. Этот модуль работает без LLM для первичной сортировки, что обеспечивает скорость и надёжность.
- Долговременный банк памяти: выделенное хранилище Hindsight Cloud (recallops-dev), где сохраняются структурированные воспоминания о разрешениях инцидентов.
- Панель управления для инженера: веб-интерфейс, созданный с помощью React, Vite и Tailwind CSS. Он предоставляет рабочее пространство для триирования и подтверждения действий в реальном времени.
Как это работает на практике
Процесс начинается в момент регистрации инцидента. RecallOps детерминированно извлекает симптомы, такие как HTTP-коды ошибок, уровни логирования и типы исключений. Эта информация используется для поиска в исторической памяти.
- Запрос к исторической памяти: система ищет в банке памяти Hindsight похожие прошлые инциденты, основываясь на извлечённых симптомах. Это позволяет мгновенно предложить инженеру проверенные решения, которые сработали ранее.
- Анализ и триирование: если точного совпадения нет, в дело вступает детерминированный движок анализа. Он классифицирует проблему и предлагает стандартные шаги диагностики, не прибегая к дорогостоящим запросам к большим языковым моделям на этом этапе.
- Подтверждение и сохранение: после того как инженер применяет решение и подтверждает его успешность, вся цепочка событий — от симптомов до предпринятых действий и финального результата — структурируется и сохраняется в долговременной памяти Hindsight.
Преимущества подхода
Такой подход кардинально меняет процесс управления инцидентами. Вместо того чтобы каждый раз начинать с нуля, команда опирается на накопленный опыт. Это сокращает среднее время восстановления (MTTR), уменьшает количество повторяющихся ошибок и снижает когнитивную нагрузку на инженеров в стрессовых ситуациях. Детерминированный анализ на первом этапе гарантирует, что система не будет предлагать "галлюцинации" или непроверенные гипотезы, а панель управления даёт инженеру полный контроль над процессом, требуя подтверждения для каждого важного шага.