Идея возникла из бытовой усталости: очередной алерт Zabbix о смене скорости на порту коммутатора домашней лаборатории пришёл по дороге с работы. Вместо тонкой ручной настройки мониторинга автор решил развернуть локальную LLM и сделать из неё слой интеллектуальной обработки событий — с триажем, подавлением шума и краткими рекомендациями по диагностике.
Проект задуман как отдельный модуль поверх Zabbix, не затрагивающий сам мониторинг. Система принимает webhook-события, нормализует их, тянет дополнительный контекст через Zabbix API, подавляет малозначимые алерты и формирует содержательные уведомления в Matrix и по email. LLM подключается там, где нужно обогащение и предположения о причинах, — но не принимает автономных решений и не выполняет команды. Audit trail фиксирует все принятые решения. Управление инцидентами, обучение собственной модели и универсальный движок поиска корневых причин намеренно вынесены за периметр.
Центральная тема первой части цикла — зависимость качества ответа нейросети от постановки задачи. Автор, по образованию инженер-архитектор ИТ-инфраструктуры, утверждает: проблемы при работе с LLM возникают по той же причине, что и при работе с командой разработчиков, — из-за размытой цели. Запрос вида «сделай умную систему над Zabbix, чтобы она понимала важность алертов» не содержит ни границ системы, ни логики маршрутизации, ни поведения при недоступности LLM, ни правил подавления алертов. Нейросеть ответит — но уверенно предложит решение, в котором не будет нужной логики корреляции, доставки или аудита. Итог — не рабочий прототип, а набор архитектурных долгов.
Размытый запрос к нейросети («сделай умнее») даёт тот же результат, что плохое ТЗ: галлюцинации, противоречия и архитектурные долги.
Альтернативный подход: сначала сформировать ТЗ и HLD (высокоуровневую архитектуру), зафиксировать периметр, описать требования к каждому компоненту — и только потом передавать декомпозированные задачи нейросети. При наличии цели, ограничений, требований и детализации LLM перестаёт «размывать» задачу и начинает двигаться в заданном направлении. Именно этот принцип автор использовал для пет-проекта, написав весь основной материал заранее и разбив его на четыре части.
Подход не нов — он повторяет классическую инженерную практику: хорошее техническое задание экономит время на переделках. Разница в том, что здесь «исполнитель» — коммерческая LLM, которая не может сама уточнить параметры задачи, как опытный инженер на встрече. Если контекст не задан явно, модель заполняет пробелы собственными допущениями — и чем шире пробел, тем дальше результат от реальности. Следующие части цикла посвящены выбору локальной LLM для self-hosted инфраструктуры, формированию HLD и LLD, а также итогам всего эксперимента.
