morfix.ru
Проблема, которая встала передо мной в июне
Когда я планировал отпуск в начале лета, возник классический IT-конфликт: два больших проекта в критической фазе, новичок в команде еще не готов к самостоятельному мониторингу, а отказываться от двух недель отдыха не хотелось. Я начал размышлять о том, как можно передать часть своего опыта анализа статусов проектов чему-то более надежному, чем письма от коллег.
Решение пришло неожиданно: а что если обучить собственный LLM анализировать метрики моих проектов так же, как это делаю я? Звучало амбициозно, но оказалось вполне реализуемо.
Что я хотел автоматизировать
Ежедневный мониторинг в моих проектах включал рутинные операции:
- Проверка pipeline-ов GitLab CI/CD — количество падений за день, время их разрешения
- Анализ метрик в Datadog — CPU, память, time to first byte
- Просмотр Jira-дошборда — количество новых багов, статус критических задач
- Изучение логов ошибок в Sentry — выявление паттернов новых проблем
- Проверка тестового покрытия в SonarQube — падение/рост метрик качества
Весь процесс занимал 30-40 минут каждый день и состоял больше из анализа, чем из действий. Идеальный кандидат для автоматизации.
Как я готовил LLM к работе
Этап первый: сбор контекста
Первая ошибка большинства людей — они думают, что можно просто скормить ИИ JSON с метриками и ждать чуда. На самом деле нужно дать модели структурированное понимание вашего бизнеса.
Я подготовил документ, где описал:
- Архитектурный контекст — что такое мой сервис, какие у него критичные компоненты, какие падения приемлемы, какие нет
- SLA и метрики успеха — какой аптайм у нас обещан, какой желаемый размер очереди задач, нормальный уровень ошибок
- Исторические паттерны — когда обычно падают pipeline-ы (деплой в 3 часа ночи — нормально), когда растет нагрузка (вечер пятницы)
- Процессы реагирования — кого звать при критичной ошибке, какие проблемы решаются автоматически, какие требуют ручного вмешательства
Этап второй: подготовка данных
Я написал простой скрипт на Python, который собирает данные из всех наших инструментов и преобразует их в единый JSON с понятной структурой. Важный момент: не все метрики равны. Я вручную расставил приоритеты и пороги alerting.
Например, если CPU 80% — это уведомление, если 95% — это warning, если 99% — это critical. Но эти пороги разные для разных сервисов.
Этап третий: fine-tuning через примеры
Я взял свои прошлые анализы проектов за два месяца и переформатировал их в пары “входные данные → мой анализ”. Получилось около 40 примеров достаточной длины. Этого хватило, чтобы модель поняла мой стиль анализа.
Ключевые примеры, которые я включил:
- День, когда все хорошо — чтобы модель не создавала панику понапрасну
- День с одной проблемой — как ее диагностировать
- День с несколькими проблемами одновременно — как расставлять приоритеты
- День с рецидивом известной проблемы — чтобы модель запоминала контекст
Конкретная реализация
Я выбрал подход с использованием OpenAI API и собственным промптом, потому что fine-tuning через их систему казался излишней сложностью для моего масштаба.
Архитектура получилась такой:
- Cronjob каждый день в 9:00 запускает сборщик метрик
- Данные отправляются в LLM с контекстом проекта и историей проблем за последнюю неделю
- Модель генерирует отчет с выделением аномалий и рекомендациями
- Отчет отправляется в Slack, одновременно сохраняется в базу для истории
- Если обнаружена критичная проблема, отправляется дополнительное уведомление в чат on-call
Что оказалось сложнее всего
Борьба с галлюцинациями
Модель иногда генерировала “предложения” вроде “проверьте конфиг такого-то сервера”, хотя я никогда об этом не писал. Решение: я добавил explicit instruction, что модель может рекомендовать только то, что прямо описано в ее контексте.
Ложные срабатывания
Сначала LLM слишком часто поднимала alarm. Пришлось добавить слой фильтрации: если метрика вышла за пределы нормы менее чем на 10%, это не критично. Если эта метрика уже была в таком состоянии вчера, это не новая проблема.
Контекст длинных историй
При анализе рецидивирующих проблем модель забывала детали из истории более чем месячной давности. Я ограничил исторический контекст двумя неделями — этого хватает для реальной работы.
Результаты и чему я научился
За две недели отпуска я получал каждое утро отчет, который заменял мой 30-минутный обход. Два раза LLM поймала проблемы, которые я бы точно заметил, когда вернусь (растущая очередь задач в очереди), и один раз система переквалифицировала обычное падение pipeline-а как симптом более глубокой проблемы.
Когда я вернулся, нужно было потратить 2-3 часа на настройку и калибровку, потому что за две недели модель немного “дрейфовала” в сторону излишней осторожности. Но в целом система себя оправдала.
Главный вывод: LLM работает хорошо не когда вы просто даете ей данные, а когда вы научили ее вашему способу думать через примеры и контекст. Это требует больше работы вначале, но экономит время после.
Практический чеклист для своего проекта
Если вы захотите повторить это у себя:
- Определите, какой мониторинг отнимает больше всего времени и требует меньше действий (идеально — только анализ)
- Соберите 30-50 примеров ваших прошлых анализов в структурированном виде
- Напишите документ с контекстом проекта, SLA и нормальными паттернами
- Начните с простого промпта без fine-tuning, посмотрите результаты
- Добавляйте правила фильтрации поэтапно, не все сразу
- Проверяйте качество в течение недели, прежде чем полностью доверять системе
Заключение
Идея обучить LLM мониторить мои проекты пришла из практической необходимости, а не из желания экспериментировать с ИИ. Но процесс показал, что современные языковые модели вполне способны выполнять специализированную работу, если их правильно подготовить. Это не замена вашему мониторингу и alerting-системам, но отличное дополнение для анализа и рекомендаций.
Главное — не ожидайте, что модель будет работать “из коробки”. Инвестируйте время в подготовку контекста и примеров, и система окупит эти затраты многократно, освобождая вас для более важных задач.