Как я Zabbix с LLM дружил в свободное время. Архитектурный обзор взаимодействия с нейросетью. Часть 1 «При чем тут ТЗ»

Введение

Это первая статья из цикла о том, как при четкой формулировке задачи и описании целевой архитектуры получилось собрать для self-hosted инфраструктуры MVP сервис по анализу алертов мониторинга с участием LLM.

В процессе написания статья разрослась до неимоверных размеров, поэтому пришлось поделить ее аж на 4 части (ссылки буду добавлять по мере выпуска, а т.к. основной материал готов и осталось только оформить – постараюсь загружать раз в одну-две недели).

Часть 1: Вводная и формирование ТЗ (Вы здесь)

Часть 2: Выбор локальной LLM

Часть 3: Формирование HLD и немного LLD

Часть 4: Что из этого вышло

Рождение идеи

Так как навыки программирования у меня на уровне чуть выше начального, а времени разбираться недостаточно, пришла идея применить свои знания и навыки по построению архитектуры, обернуть в ТЗ, составить HLD и LLD и заставить уже коммерческую нейросеть поэтапно готовить решения.

Собственно, все части – это путь от составления архитектуры до применения решения.

О взаимодействии с нейросетями

Со времени появления LLM появились два противоположных мнения:

Мнение 1 – “Архитекторы/программисты/инженеры/{вставьте нужное} не нужны, все сделает ИИ”.

Мнение 2 – “ИИ постоянно галлюцинируют, ничего серьезного они предложить не способны”.

На практике же оба тезиса неверны. Если подойти к вопросу в стиле “сделай красиво”, то на выходе действительно получится примерно то же самое, что обычно получается от плохо сформулированного технического задания: набор домыслов, недопонимания, галлюцинаций и вообще противоречащих идей. Эдакий “разговор слепого с глухим”.

С другой стороны, если отдать нейросети не рассуждения о кнопке “сделать хорошо”, а декомпозированную задачу, разработанную человеком, то картина резко меняется и, по большей части, нейросеть начинает придерживаться заданной проектной логики, потому что:

• есть цель;

• есть ограничения;

• есть требования;

• есть архитектура;

• есть детализация.

То есть имеется все необходимое для пошаговой реализации.

Именно такой подход использовался мной для этого домашнего пет-проекта: надстройка над Zabbix, которая умеет принимать алерты, обогащать их контекстом, делать триаж, строить советы по исправлению, отправлять уведомления и постепенно превращаться в что-то похожее на аккуратный AIOps-пайплайн.

В этой статье не будет описаний ни FastAPI, ни Redis, ни Matrix, ни Ollama (о них немного в следующих выпусках). Здесь речь про зависимость качества ответа нейросети от поставленной задачи.

С чего начинать технический проект

По опыту ^[1] инженера-архитектора ИТ-инфраструктуры могу сказать, что в реальной жизни (работе и не только) проблемы возникают не потому, что кто-то не знает синтаксиса языка программирования или забыл элемент на диаграмме, а в осознании цели и конечного результата.

Например, формулировки вида:

“Придумай мне, чтобы алерты стали умнее и мне не мешали”

в предметном переложении на текущую задачу, содержат не более вводных, чем:

“Сделай мне кнопку Быстро сделать хорошо”

То есть задача не содержит никаких полезных вводных информационных данных, на основе которых можно было бы спроектировать решение и прикинуть объем работ даже для опытного архитектора и толпы сеньоров-программистов, не то, что для нейросети.

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

Поэтому, даже взаимодействуя с нейросетью, необходимо точно и четко формулировать свои мысли и задачи, если хочется извлечь что-то полезное:

• сформировать ТЗ;

• описать HLD.

Только после этих шагов задуматься о реализации.

Звучит, как очередное бумагомарательство, но эта последовательность как раз и позволит из нескольких запросов к нейросети получить рабочую заготовку.

Постановка задачи

В самом начале статьи уже было описано, как родилась идея. Проясню более детально.

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

Алерт только декларирует:

“Событий X произошло, отметка времени Y, важность события Z”.

Инженеру же важнее быстро понять:

• это действительно важно?

• это симптом или первопричина?

• куда смотреть в первую очередь?

• надо ли будить по этому поводу кого-то живого ночью в выходной?

Вот тут идея начала обрастать деталями – нужно собрать над Zabbix отдельный слой обработки событий, который не сломает сам мониторинг, но сможет:

• принимать webhook-события;

• складывать их в надежный пайплайн;

• тянуть дополнительный контекст;

• подавлять информационный шум;

• использовать LLM там, где это действительно полезно (обогащение, предположения, рекомендации, подавление шума);

• формировать более содержательные уведомления;

• вести аудит принятых решений.

В таком виде задача уже начинает походить на проект, но все равно недостаточно для эффективного ТЗ.

Что сделать, чтобы получить мусор вместо ответа?

Чтобы не идеализировать процесс, необходимо детальнее раскрыть как и почему будет выглядеть плохой вариант взаимодействия.

Например запрос:

“Сделай мне умную систему над Zabbix, чтобы она понимала важность алертов, сама их анализировала, не создавала лишний шум, а важные сразу объясняла и давала рекомендации”.

В данном запросе нет фиксации и понимания:

• где заканчивается система и где начинаются внешние сервисы;

• кто принимает финальное решение;

• что делать, если LLM недоступна;

• какие алерты можно подавлять, а какие нельзя;

• какие каналы уведомлений нужны;

• как отслеживать взаимодействие;

• насколько системе можно доверять в части корреляции

• и т.д.

Да нейросеть ответит на такой запрос, и даже предложит решение, но тут выяснятся первые проблемы – что в вашем решении будут отсутствовать или вам не подойдет:

• логика ^[2] маршрутизации;

• логика доставки;

• логика аудита

• логика корреляции

• и т.д.

А нейронка будет полностью уверена в своей правоте, давая все более далекие от реальности реализации.

В итоге получится не решение задачи, а набор архитектурных долгов.

Постановка задачи: границы

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

Что входит в периметр

• прием webhook-событий из Zabbix;

• нормализация событий;

• асинхронная обработка;

• хранение состояния по событиям и решениям;

• обогащение событий через Zabbix API;

• триаж событий с низкой важностью;

• предоставление рекомендаций по уведомлениям;

• корреляция;

• отправка в Matrix и по email (для меня);

• audit trail.

Что не входит в периметр

• управление инцидентами;

• автоматическое выполнение рекомендуемых команд;

• обучение ^[3] собственной модели;

• движок по определению корневых причин на все случаи жизни.

С определением границ периметра решения нейросеть уже с меньшей вероятностью будет съезжать в галлюцинации и начнет двигаться в нужном направлении.

Однако это еще не все.

Фиксация ТЗ

Для нейронки ТЗ не должно выглядеть, как оформленный по ГОСТ документ с подписями участников процесса согласования. Оно должно грамотно формулировать постановку задачи.

Для моего проекта базовая версия требований выглядела следующим образом:

1. Система должна надежно принимать события из Zabbix.

• webhook должен быть защищен токеном;

• payload должен валидироваться;

• при сбое тяжелой обработки событие не должно теряться.

2. Система должна разделять прием и обработку

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

3. Для критичных событий (High, Disaster) нельзя полностью полагаться на LLM, т.к. риск ошибки ^[4] модели высок.

4. Для событий уровня Average оставить возможность настройки за инженером– либо доставка, по аналогии с критичными событиями, либо по логике событий с низкой критичностью.

5. События с низкой критичностью (Warning и ниже) передаются для триажа и проводится анализ LLM для вынесения вердикта об уведомлении инженера.

6. Для всех событий проводится анализ о корневых причинах появления алерта (RCA по шаблонам или, в отсутствии оных, рассуждением LLM) с последующими рекомендуемыми шагами только для диагностики (чтение статистики и т.д.) от LLM без внесения изменений (как моделью, так и в указаниях инженеру).

7. Использование audit log, доступного, как отдельный сервис, с возможностью получения информации:

• о поступившем событии;

• прохождении этапов обработки;

• решении политики;

• решении LLM;

• используемым каналам доставки и содержимом.

8. Кратковременное хранение состояния для принятия решений о:

• подавлении оповещения о событии;

• обнаружении флапа в заданный инженером период;

• обнаружении восстановления после события;

• построении корреляции в заданном инженером промежутке времени;

• выполнении дедупликации событий;

• хранении информации для построения audit log.

9. Работа системы в локальном контуре.

10. Иметь возможность создания детерминированной логики для корреляции поступающих событий и определения корневых причин.

11. Выполнение LLM корреляции событий в отсутствии детерминированной логики.

12.  Независимость от используемой ОС для возможности переноса на другие хосты и системы ( использование Docker).

Выше описаны основные идеи из сформированного ТЗ. На самом деле на его составление ушло больше двух недель (и это только для пет-проекта для домашней лаборатории) и составило оно в Obsidian более 2-х тысяч слов.

Почему именно ТЗ поможет во взаимодействии с нейросетью

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

Во-вторых: вы уже можете сами понять, из каких модулей система будет состоять, их интеграцию, взаимодействие с системой от пользователя и приблизитесь вплотную к пониманию и составлению HLD.

Соответственно нейросети не надо будет фантазировать насчет ваших желаний, а работать в предметном пространстве, что существенно уменьшит количество галлюцинаций и ошибок в получаемом решении.

Итог первого этапа

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

На выходе появилась не реализация, но более важная вещь на старте проекта – четко поставленная задача.

Что будет дальше

В следующей статье перейдем к другому важному этапу: составлению требований к LLM, критериям выбора и, собственно, выбору модели.

Затем перейдем к формированию HLD и LLD (совсем немного), и, в заключительной части, описание реализации и результата.