Введение
Это первая статья из цикла о том, как при четкой формулировке задачи и описании целевой архитектуры получилось собрать для self-hosted инфраструктуры MVP сервис по анализу алертов мониторинга с участием LLM.
В процессе написания статья разрослась до неимоверных размеров, поэтому пришлось поделить ее аж на 4 части (ссылки буду добавлять по мере выпуска, а т.к. основной материал готов и осталось только оформить - постараюсь загружать раз в одну-две недели).
Часть 1: Вводная и формирование ТЗ (Вы здесь)
Часть 2: Выбор локальной LLM
Часть 3: Формирование HLD и немного LLD
Часть 4: Что из этого вышло
Рождение идеи
В очередной раз по пути домой с работы я ловлю на почту очередной алерт Zabbix от моей домашней лаборатории, что, дескать, на порту коммутатора изменилась скорость и это очень-очень (прямо наверняка!) важно.
Тонкая настройка мониторинга – не наш путь, нужно что-то более автоматизированное и "интеллектуальное". Так и родилась идея развернуть локально LLM , прикрутить к системе мониторинга для принятия решения о тушении некоторого "шума" и, как бонус, выдачи предположений почему так получилось со списком кратких команд диагностики события.
Так как навыки программирования у меня на уровне чуть выше начального, а времени разбираться недостаточно, пришла идея применить свои знания и навыки по построению архитектуры, обернуть в ТЗ, составить HLD и LLD и заставить уже коммерческую нейросеть поэтапно готовить решения.
Собственно, все части – это путь от составления архитектуры до применения решения.
О взаимодействии с нейросетями
Со времени появления LLM появились два противоположных мнения:
Мнение 1 - "Архитекторы/программисты/инженеры/{вставьте нужное} не нужны, все сделает ИИ".
Мнение 2 - "ИИ постоянно галлюцинируют, ничего серьезного они предложить не способны".
На практике же оба тезиса неверны. Если подойти к вопросу в стиле "сделай красиво", то на выходе действительно получится примерно то же самое, что обычно получается от плохо сформулированного технического задания: набор домыслов, недопонимания, галлюцинаций и вообще противоречащих идей. Эдакий "разговор слепого с глухим".
С другой стороны, если отдать нейросети не рассуждения о кнопке "сделать хорошо", а декомпозированную задачу, разработанную человеком, то картина резко меняется и, по большей части, нейросеть начинает придерживаться заданной проектной логики, потому что:
есть цель;
есть ограничения;
есть требования;
есть архитектура;
есть детализация.
То есть имеется все необходимое для пошаговой реализации.
Именно такой подход использовался мной для этого домашнего пет-проекта: надстройка над Zabbix, которая умеет принимать алерты, обогащать их контекстом, делать триаж, строить советы по исправлению, отправлять уведомления и постепенно превращаться в что-то похожее на аккуратный AIOps-пайплайн.
В этой статье не будет описаний ни FastAPI, ни Redis, ни Matrix, ни Ollama (о них немного в следующих выпусках). Здесь речь про зависимость качества ответа нейросети от поставленной задачи.
С чего начинать технический проект
По опыту инженера-архитектора ИТ-инфраструктуры могу сказать, что в реальной жизни (работе и не только) проблемы возникают не потому, что кто-то не знает синтаксиса языка программирования или забыл элемент на диаграмме, а в осознании цели и конечного результата.
Например, формулировки вида:
"Придумай мне, чтобы алерты стали умнее и мне не мешали"
в предметном переложении на текущую задачу, содержат не более вводных, чем:
"Сделай мне кнопку Быстро сделать хорошо"
То есть задача не содержит никаких полезных вводных информационных данных, на основе которых можно было бы спроектировать решение и прикинуть объем работ даже для опытного архитектора и толпы сеньоров-программистов, не то, что для нейросети.
В таком формате нейронка размывает задачу еще сильнее, словно разговорчивый генератор неопределенности, постоянно галлюцинируя и отдавая в корне неверные ответы, так как не может сама уточнить у вас нужные параметры, как опытный инженер или архитектор.
Поэтому, даже взаимодействуя с нейросетью, необходимо точно и четко формулировать свои мысли и задачи, если хочется извлечь что-то полезное:
сформировать ТЗ;
описать HLD.
Только после этих шагов задуматься о реализации.
Звучит, как очередное бумагомарательство, но эта последовательность как раз и позволит из нескольких запросов к нейросети получить рабочую заготовку.
Постановка задачи
В самом начале статьи уже было описано, как родилась идея. Проясню более детально.
При эксплуатации системы мониторинга, связанной с инфраструктурой, быстро приходит понимание, что "получить алерт" и ответить на вопрос "как быстро понять причину и диагностировать" — это не одно и то же.
Алерт только декларирует:
"Событий X произошло, отметка времени Y, важность события Z".
Инженеру же важнее быстро понять:
это действительно важно?
это симптом или первопричина?
куда смотреть в первую очередь?
надо ли будить по этому поводу кого-то живого ночью в выходной?
Вот тут идея начала обрастать деталями - нужно собрать над Zabbix отдельный слой обработки событий, который не сломает сам мониторинг, но сможет:
принимать webhook-события;
складывать их в надежный пайплайн;
тянуть дополнительный контекст;
подавлять информационный шум;
использовать LLM там, где это действительно полезно (обогащение, предположения, рекомендации, подавление шума);
формировать более содержательные уведомления;
вести аудит принятых решений.
В таком виде задача уже начинает походить на проект, но все равно недостаточно для эффективного ТЗ.
Что сделать, чтобы получить мусор вместо ответа?
Чтобы не идеализировать процесс, необходимо детальнее раскрыть как и почему будет выглядеть плохой вариант взаимодействия.
Например запрос:
"Сделай мне умную систему над Zabbix, чтобы она понимала важность алертов, сама их анализировала, не создавала лишний шум, а важные сразу объясняла и давала рекомендации".
В данном запросе нет фиксации и понимания:
где заканчивается система и где начинаются внешние сервисы;
кто принимает финальное решение;
что делать, если LLM недоступна;
какие алерты можно подавлять, а какие нельзя;
какие каналы уведомлений нужны;
как отслеживать взаимодействие;
насколько системе можно доверять в части корреляции
и т.д.
Да нейросеть ответит на такой запрос, и даже предложит решение, но тут выяснятся первые проблемы – что в вашем решении будут отсутствовать или вам не подойдет:
логика маршрутизации;
логика доставки;
логика аудита
логика корреляции
и т.д.
А нейронка будет полностью уверена в своей правоте, давая все более далекие от реальности реализации.
В итоге получится не решение задачи, а набор архитектурных долгов.
Постановка задачи: границы
В первую очередь необходимо зафиксировать периметр, потому что вся система не должна быть новым Zabbix, а всего лишь прослойкой обработки событий, то есть отдельным внешним модулем для системы мониторинга.
Что входит в периметр
прием webhook-событий из Zabbix;
нормализация событий;
асинхронная обработка;
хранение состояния по событиям и решениям;
обогащение событий через Zabbix API;
триаж событий с низкой важностью;
предоставление рекомендаций по уведомлениям;
корреляция;
отправка в Matrix и по email (для меня);
audit trail.
Что не входит в периметр
управление инцидентами;
автоматическое выполнение рекомендуемых команд;
обучение собственной модели;
движок по определению корневых причин на все случаи жизни.
С определением границ периметра решения нейросеть уже с меньшей вероятностью будет съезжать в галлюцинации и начнет двигаться в нужном направлении.
Однако это еще не все.
Фиксация ТЗ
Для нейронки ТЗ не должно выглядеть, как оформленный по ГОСТ документ с подписями участников процесса согласования. Оно должно грамотно формулировать постановку задачи.
Для моего проекта базовая версия требований выглядела следующим образом:
Система должна надежно принимать события из Zabbix.
webhook должен быть защищен токеном;
payload должен валидироваться;
при сбое тяжелой обработки событие не должно теряться.
Система должна разделять прием и обработку
Потому что обогащение данными, графики, триаж и составление рекомендаций могут занимать приличное время.
Для критичных событий (High, Disaster) нельзя полностью полагаться на LLM, т.к. риск ошибки модели высок.
Для событий уровня Average оставить возможность настройки за инженером– либо доставка, по аналогии с критичными событиями, либо по логике событий с низкой критичностью.
События с низкой критичностью (Warning и ниже) передаются для триажа и проводится анализ LLM для вынесения вердикта об уведомлении инженера.
Для всех событий проводится анализ о корневых причинах появления алерта (RCA по шаблонам или, в отсутствии оных, рассуждением LLM) с последующими рекомендуемыми шагами только для диагностики (чтение статистики и т.д.) от LLM без внесения изменений (как моделью, так и в указаниях инженеру).
Использование audit log, доступного, как отдельный сервис, с возможностью получения информации:
о поступившем событии;
прохождении этапов обработки;
решении политики;
решении LLM;
используемым каналам доставки и содержимом.
Кратковременное хранение состояния для принятия решений о:
подавлении оповещения о событии;
обнаружении флапа в заданный инженером период;
обнаружении восстановления после события;
построении корреляции в заданном инженером промежутке времени;
выполнении дедупликации событий;
хранении информации для построения audit log.
Работа системы в локальном контуре.
Иметь возможность создания детерминированной логики для корреляции поступающих событий и определения корневых причин.
Выполнение LLM корреляции событий в отсутствии детерминированной логики.
Независимость от используемой ОС для возможности переноса на другие хосты и системы ( использование Docker).
Выше описаны основные идеи из сформированного ТЗ. На самом деле на его составление ушло больше двух недель (и это только для пет-проекта для домашней лаборатории) и составило оно в Obsidian более 2-х тысяч слов.
Почему именно ТЗ поможет во взаимодействии с нейросетью
Во-первых: вы сами для себя уже определяетесь, что именно вы хотите получить от системы, выставляете осязаемые границы решения, распределяете зоны ответственности за процесс обработки входных данных.
Во-вторых: вы уже можете сами понять, из каких модулей система будет состоять, их интеграцию, взаимодействие с системой от пользователя и приблизитесь вплотную к пониманию и составлению HLD.
Соответственно нейросети не надо будет фантазировать насчет ваших желаний, а работать в предметном пространстве, что существенно уменьшит количество галлюцинаций и ошибок в получаемом решении.
Итог первого этапа
В данной статье был пройден самый тяжелый и наименее интересный подготовительный этап, насыщенный исключительно требованиями и правилами к будущему решению, фиксацией границ решения и зоны ответственности LLM.
На выходе появилась не реализация, но более важная вещь на старте проекта – четко поставленная задача.
Что будет дальше
В следующей статье перейдем к другому важному этапу: составлению требований к LLM, критериям выбора и, собственно, выбору модели.
Затем перейдем к формированию HLD и LLD (совсем немного), и, в заключительной части, описание реализации и результата.