Где ИИ действительно снимает боль
Сетевой отдел обычно тратит часы на одно и то же: однотипные алерты ночью, длинные хвосты syslog без ясной причины, разнородные сообщения от вендоров, которые говорят об одном и том же разными словами. Здесь ИИ полезен не как «волшебная кнопка», а как ускоритель дел, которые и так выполняются вручную: сведение фактов, нормализация сообщений, подсказки по проверкам, черновики отчётов. Главное — дать модели правильный контекст и ограничить круг задач, где она имеет право что-то предлагать.
Карта задач и источников данных
Идея проста: вместо «обучим ИИ всему» — связываем конкретную задачу со своим набором данных и понятным критерием успеха.
| Задача | Данные | Подход | Ограничения |
|---|---|---|---|
| Быстрый дайджест инцидента | syslog, SNMP traps, таймлайн событий | LLM с шаблоном ответа (JSON) | Нужны фильтры по шуму и окна событий |
| Нормализация сообщений разных вендоров | syslog, telemetry | LLM + словарь соответствий | Требует версионирования словаря |
| Предложение команд проверки | инвентарь, топология, вендор, версия | LLM с «runbook»-контекстом | Проверять команды на опасные действия |
| Поиск аномалий в трафике | NetFlow/sFlow, метрики | Классика ML (изол. лес, STL) | Нужны пороги и сезонность |
| Выявление «болтливых» устройств | NetFlow, SNMP ifHC* | Heuristics + ML | Ложные срабатывания при бэкапах |
| Ранжирование алертов | История инцидентов | ML по признакам + LLM для резюме | Нужна разметка прошлых кейсов |
Быстрые сценарии LLM
Дайджест инцидента в структурированном виде
LLM получает нарезку логов за окно времени и возвращает краткое резюме с фактами и гипотезами. Формат ответа фиксируем заранее.
{
"сводка": "Потеря связи с узлом edge-sw2 в 03:12–03:18",
"ключевые_события": [
"03:11:57 PoE overload on Gi1/0/24",
"03:12:04 Link down Gi1/0/24",
"03:12:07 LACP removed member Po1"
],
"возможные_причины": ["Перегрузка по PoE", "Неисправный кабель/порт"],
"что_проверить": [
"show power inline",
"show etherchannel summary",
"замер ошибок на порту"
],
"оценка_риска": "средний"
}
Это не «диагноз», а ускоренное приведение фактов к виду, пригодному для решения.
Нормализация словаря событий
У разных вендоров «порт ушёл вниз» звучит по-разному. LLM по таблице соответствий приводит сообщения к единому «каноническому» типу: LINK_DOWN, AUTH_FAIL, ARP_STORM. Это резко сокращает шум в корреляции.
Подсказки к runbook
Модель получает: тип устройства, версию прошивки, схему включения и последний diff конфигурации. Ответ — короткий список безопасных команд проверки и последовательность действий. Опасные операции (reload, write) в список не попадают — это жёсткое правило.
ML для аномалий в трафике
Признаки, которые говорят больше всего
Для NetFlow полезны не только объемы. Работают плотность и энтропия источников/портов, доля малых пакетов, всплески новых направлений, изменение соотношения TCP/UDP, редкие порты в нерабочее время. Из этого получается лёгкая модель с верхними порогами по скользящему окну.
Как уменьшить ложные срабатывания
Отделите день недели и часы — ночные бэкапы и окна обновлений не должны «гореть». Учтите сезонность (например, конец месяца). Заведите список «ожидаемых пиков» и минимальный таймаут до алерта (сначала предупреждение, затем подтверждённая аномалия).
Где граница LLM и классики
LLM полезна, когда нужно объяснить «что это похоже на…», связать событие с изменениями и подсказать ход проверки. «Увидеть иголку в статистике» всё ещё надёжнее классическими методами с прозрачными порогами.
Интеграция с NMS и чат-интерфейс для NOC
Удобнее всего работать через чат-слой, который «понимает» инвентарь и знает топологию. В промпт кладём только факты: название узла, класс, вендор и версию, последние изменения, кусок лога и текущие метрики. Запрещаем «выдумывать» команды, которых нет в вендорной матрице.
Шаблон запроса к ассистенту:
Контекст:
- Устройство: edge-sw2, Cisco C9300, 17.9.3
- Последние изменения: обновление PoE-профиля 22:15
- Логи (03:11–03:18): <вырезка>
- Метрики: ifErrors↑ на Gi1/0/24, PoE power cap достигнут
Задача:
1) Короткое резюме (до 3 предложений).
2) Безопасные команды проверки (до 6 строк).
3) Вероятные причины с вероятностями.
4) Что зафиксировать в отчёте (1–2 пункта).
Ответ приходит в одном стиле, им удобно делиться в тикете.
Риски и правила
- Галлюцинации. Сократите контекст до фактов, запретите опасные действия, проверяйте команды по списку разрешённых.
- Конфиденциальность. Логи могут содержать имена и IP. Маскируйте PII, убирайте чувствительные сегменты. Делайте аудиторский лог обращений к ассистенту.
- Версионирование. Сохраняйте «версии подсказок» и тестируйте их на контрольном наборе инцидентов: одна правка промпта не должна ломать прежние ответы.
- Права и трассируемость. Ассистент не выполняет изменения, только предлагает. Выполнение — через стандартные процедуры и ответственных.
Как измерять пользу
Запускаем пилот на одном домене сети и через восемь недель сравниваем метрики.
| Метрика | Базовый уровень | Цель через 8 недель |
|---|---|---|
| MTTD (время до обнаружения) | 9 мин | 4–5 мин |
| MTTR (время до восстановления) | 62 мин | 40–45 мин |
| Доля «шума» в алертах | 38% | ≤ 20% |
| Инциденты с неполным отчётом | 27% | ≤ 10% |
| Повторные эскалации по одной причине | 14% | ≤ 7% |
Считать лучше автоматически из тикет-системы и NMS, чтобы не опираться на память.
Двухнедельный чек-лист запуска
- День 1–2. Соберите источники: syslog, NetFlow/sFlow, инвентарь, базовую топологию.
- День 3. Напишите простые парсеры и нормализатор временных меток; заведите хранилище «срезов» инцидентов.
- День 4–5. Соберите 15–20 реальных кейсов, где есть «правильный разбор» — это станет тестовым набором.
- День 6. Подключите LLM с шаблоном ответа в JSON и со словарём событий.
- День 7. Настройте классический детектор аномалий на NetFlow для одного узла (изолированный лес или простые пороги со скользящим средним).
- День 8. Первый чат-интерфейс для NOC с короткими кнопками: «Резюме», «Команды проверки», «Факты для отчёта».
- День 9–10. Обкатываем на дневной смене, фиксируем ложные ответы, пополняем словарь соответствий.
- День 11. Добавляем ранжирование алертов по риску и влиянию (правила + простая модель).
- День 12–13. Включаем ночную смену; учим ассистента писать короткие резюме для тикетов.
- День 14. Первая ретроспектива: что сработало, какие промпты и правила оставить, что внести в «обязательный минимум».
FAQ
Можно ли давать модели доступ к конфигам полностью?
Лучше нарезать: только изменённые фрагменты и справочные части (версии, интерфейсы, VRF). Полные конфиги — по запросу и через политику доступа.
Как хранить контекст, чтобы он не «уползал» в ответы?
Делите его на «факты» и «гипотезы». В промпт передавайте только факты, а гипотезы пусть формирует модель с явной пометкой.
Что делать с редкими экзотическими событиями?
Собирайте «карточки кейсов» после каждого инцидента. Через пару месяцев из этого вырастает библиотека примеров, которая сильнее любого универсального гайда.
Сколько времени реально экономит ассистент?
На типовом инциденте уровня доступа — 10–15 минут на сведение фактов и составление отчёта. На десятках кейсов в месяц это превращается в часы.
Что оставить на перспективу
После пилота стоит добавить два направления: автогенерация «пост-морем» по чек-листу и обогащение инцидентов внешними зависимостями (изменения в CMDB, календарь релизов, работы провайдеров). Так система перестаёт быть «говорящим логом» и становится помощником, который подсказывает, где риск повторится и что с этим сделать заранее.