Спросите себя, что было результатом расследования сбоя десять лет назад, пять, год. А как обстоят дела сейчас? Ответ будет примерно одинаковый – скриншот графика в рабочем чате и фраза «похоже, это база».

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

Меня зовут Надя Фердман, я руковожу продуктовым развитием платформы наблюдаемости Proto Observability.

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

Ниже расскажу, как менялось расследование сбоев и что теперь берёт на себя Proto, а что остаётся человеку.

От «что сломалось» к «почему»

Посмотрите на свою систему мониторинга, на какой вопрос она отвечает без вашего участия – «что сломалось», «где именно» или «почему»?

Чтобы было проще ответить, ниже — описание пяти этапов развития процесса расследования аварий, от максимума ручной работы к минимуму. Найдите, на каком сейчас ваша команда.

Счётчики можно было смотреть только в моменте: закрыл top и данных больше нет. Карту инфраструктуры, связи между компонентами и порядок событий держал в голове системный администратор, больше их держать было негде. Уход такого человека из команды был полноценным инцидентом сам по себе.

II — Мониторинг инфраструктуры и централизованный сбор логов.

На этом этапе развития произошло главное изменение – начался сбор инфраструктурных метрик, анализ логов происходил сразу по всем серверам, а не по одному через ssh. Но видимость была только на уровне инфраструктуры, сервис и приложения оставались слепым пятном.

III — Application Performance Monitoring.

Приложение впервые стало самостоятельным объектом наблюдения, а не набором процессов на сервере. APM-агент собирал вызовы внутри приложения и показывал не «сервер загружен», а «вот этот запрос к базе занимает три секунды из четырёх». Но всё, что было вне зоны его видимости — логи, метрики серверов, инфраструктурные изменения, — жило в других системах, и сводил их человек: по таймкодам, в шести вкладках. Ответа «в чем причина сбоя – виноват сам сервис или инфраструктура» по-прежнему не давал ни один инструмент.

IV — Observability.

Метрики, логи и трейсы оказались в одной системе наблюдаемости. Но главное изменение этапа в другом — процесс корреляции всех собираемых данных стал выполняться без участия человека. При этом готового ответа почему начался сбой по-прежнему не было.

V — ИИ-расследование.

Связанные алерты объединяются в инцидент как отдельную сущность мониторинга с охватом, влиянием, ответственным и историей. Далее модель делает то, что делал человек – строит гипотезы и проверяет каждую по совокупности данных — метрик, логов, трейсов, зависимостей, изменений. Отбрасывает не подтвердившиеся и оставляет ту, что объясняет картину целиком. На выходе не график, а текст с описанием что произошло, когда началось, какая цепочка привела к сбою, кого задело и насколько система в этом уверена.

Заметьте, в таблице столбец «Что остается человеку» не обнуляется ни на одном этапе. Принимать рекомендацию или нет решает инженер, даже если расследование произведено ИИ-алгоритмами.

ИИ-расследование аварий: как устроено в Proto Observability

До сих пор речь шла о том, как менялся сам подход к расследованию. Теперь давайте посмотрим, как процесс ИИ-анализа сбоев выглядит в живой системе – в Proto.

Платформа коррелирует метрики, логи, трейсы, зависимости и изменения. Связанные алерты объединяет в один инцидент автоматически. Новые срабатывания не создают отдельных сущностей, Proto добавляет их к уже открытому инциденту. Модуль ИИ-расследования работает поверх этого массива данных. После подключения внешней языковой модели по OpenAI-совместимому протоколу вы получаете на выходе причину проблемы и рекомендации по ее устранению в человекочитаемом формате.

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

Вернёмся к тому, с чего начали, — к артефакту. Чтобы на выходе вы увидели причину проблемы и рекомендации по ее исправлению в виде текста, а не графика, платформа последовательно выполняет работу, которую можно разделить на пять шагов.

Путь инцидента

Шаг 1. Оповещения

Алертинг в Proto работает следующим образом: правило срабатывает по условию на PromQL (в том числе на кастомные или бизнес-метрики) / MetricsQL → проверяется наличие активного окна обслуживания → политика сопоставляет лейблы алерта со своими матчерами и выбирает канал → канал доставляет уведомление в почту, Max, Telegram или по webhook .

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

Шаг 2. Корреляция: сотни алертов сворачиваются в один инцидент

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

Proto объединяет связанные алерты в инцидент автоматически и в реальном времени — по общему признаку, например по одному и тому же ресурсу или совпадающим лейблам. Новые алерты присоединяются к уже открытому инциденту, а не порождают отдельные сущности.

Важная деталь для доверия к платформе – основание корреляции видно всегда. В хронологии инцидента остаётся системная запись вида same resource: k8s_pod=<кластер>|<неймспейс>|<под> — то есть тот признак, по которому алерты были «сшиты».

У инцидента есть набор атрибутов:

Когда платформа определяет, что несколько инцидентов относятся к одной проблеме, она объединяет их: алерты и ресурсы переносятся в один инцидент, а в хронологии появляется запись в этот инцидент влит инцидент #. То же самое можно сделать и в ручном режиме, через кнопку Объединить с…. На практике это нужно, когда алерты одной аварии изначально попали в разные инциденты.

Шаг 3. Инцидент как сущность с жизненным циклом

Работу с инцидентом Proto выстраивает по ITIL — отраслевой методологии управления ИТ-услугами, на которой построены ITSM-процессы во многих компаниях. Инцидент проходит четыре этапа жизненного цикла: Обнаружен → Диагностика → Устранение → Закрыт.

Названия и порядок этапов можно настроить под принятый в вашей компании регламент. Также есть возможность назначить ответственного за инцидент и посмотреть какие за кем закреплены.

Переводит инцидент с этапа на этап человек — платформа не решает за вас, что причина уже найдена. При этом Proto автоматически закрывает инцидент после разрешения всех входящих в него алертов.

Шаг 4. Обрастание контекстом

Ответы на вопросы насколько всё плохо и что уже выяснили до вас, можно посмотреть непосредственно в карточке инцидента:

Граф распространения

Визуализируется радиуса поражения – центральный узел инцидента и связанные с ним ресурсы. Это позволяет за секунду оценить масштаб и увидеть какие компоненты инфраструктуры вовлечены.

Таймлайн

События инцидента выстраиваются на шкале времени – видно, как развивалась авария.

Хронология

По инциденту ведется журнал. В него попадают системные записи, которые Proto пишет сама – создание инцидента с признаком корреляции, объединение инцидентов, обновление ИИ-сводки и заметки инженеров, которые добавляются в поле ввода простым текстом, без Markdown. Также в Хронологии выводятся список затронутых ресурсов с указанием их типа (сервис, под Kubernetes, неймспейс, деплоймент и т.п.) и таблица связанных алертов.

Все это закрывает самую трудоемкую, но важную часть постмортема — восстановление последовательности событий, которое обычно происходит по чатам или памяти. Вся информация по инциденту — и автоматически собранная, и добавленная инженерами в комментариях – размещается Proto в одном месте.

Шаг 5. ИИ-анализ: причина аварии и рекомендации по устранению в виде текста

Проанализировав собранные данные, Proto выдает не очередной график, который нужно интерпретировать, а отвечает на вопросы «почему» и «что делать» — текстом. Платформа автоматически генерирует текстовое описание инцидента – что случилось, когда, какие сервисы затронуты, как развивалась ситуация. Если инцидент изменился, появляется отметка Устарело. Обновить сводку актуальными данными можно по клику на кнопку.

Вкладка Расследование описывает почему произошла авария:

• Первопричину и цепочку развития проблемы — как первичный сбой привёл к каскаду вторичных;

• Рекомендации по устранению;

• Уровень уверенности — например, Высокая уверенность;

• Затронутые сервисы.

Важно отметить, что инцидент-менеджмент в платформе полностью не «завязан на ИИ». Основной контур — оповещения, корреляция, жизненный цикл и обрастание контекстом — детерминированный и работает сам по себе. ИИ добавляет поверх него текстовый слой – описание, вероятные причины, постмортем и рекомендации по устранению.

Что меняется в работе дежурного инженера

До использования ИИ-агентов разбор аварии занимал дни. Приходилось анализировать алерты вручную, на глаз определять это одна проблема или пять, воспроизводить хронологию для постмортема по чатам, когда половина инженеров уже не помнит, что и в каком порядке делалось. В результате большая часть времени смены уходила не на «починить», а на выдвинуть гипотезы и проверить их.

Теперь работа инженеров строится иначе. Единицей анализа вместо алерта становится инцидент, у которого есть охват, влияние, этап, возраст, ответственный, причина и рекомендации по устранению. Видно, кто чем занят – ответственный назначается по клику, а переключатель «Только мои инциденты» позволяет видеть только то, что чинить вам. Видно на какой стадии работа — по шкале этапов, а не по последнему сообщению в чате. Видно, что уже сделано – решения и заметки пишутся в хронологию сбоя по ходу разбора, а не восстанавливаются после него по памяти. Ну и вишенка на торте – видно, в чем причина и что чинить в человекочитаемом формате. С таким подходом к расследованию аварий время команды уходит на устранение, а не на выяснение, что устранять.