AI-дежурный для одного сервера: что я бы доверил Grafana AI, а что проверяю сам

Grafana за неделю выпустила агентов для наблюдения за сервисом и расследования инцидентов, плюс песочницу, где агент готовит исправление в коде. CNCF измерила, насколько быстрее агент находит причину, если дать ему контекст. Percona выложила инструмент, который отвечает на вопрос «а что было в четверг». Для владельца бизнеса это один и тот же вопрос: кто дежурит у вашего сервера ночью и что он имеет право сделать без вас.

Что вышло

Grafana Labs 20 октября объявила три части Grafana Assistant. Watchers, постоянные агенты: вы описываете словами, что вас беспокоит в сервисе, а Assistant по истории телеметрии подбирает базовую линию и дальше периодически проверяет сигналы. Если находит критичное, сам запускает Investigations, агента для расследования по метрикам и логам. Managed Sandboxes, пока в публичном превью: агент получает код репозитория и живую телеметрию в отдельной облачной среде и готовит pull request с описанием, что изменено, почему и какие проверки прошли. Grafana подчёркивает: подтверждать восстановление в проде и решать, что выкатывать, остаётся команде.

CNCF 21 октября опубликовала замер, который мне понравился больше всех анонсов. Один и тот же агент, Claude Code на одной модели, дважды прошёл 50 сломанных кластеров Kubernetes из открытого бенчмарка SREGym. В первый раз с обычной оболочкой и kubectl, во второй с инструментами только на чтение, которые сразу отдают список текущих сбоев, историю изменений и логи с ошибками. Точность почти не изменилась: 45 верных диагнозов против 46. Изменилось время: в среднем 191 секунда против 64, верный ответ за две минуты в 60 % случаев против 86 %. Авторы пишут, что инструменты их собственные и что оба варианта промахнулись на одних и тех же трёх сбоях.

Grafana Labs 14 октября описала путь инцидента в Grafana Cloud IRM: страница вызова показывает сервис и историю срабатываний, из Slack можно спросить Assistant, что ещё горит, а расследование в Assistant Workspace править руками: добавить гипотезу, отметить опровергнутую, посмотреть источники.

Percona 16 октября показала mongo-health, открытый инструмент под Apache 2.0. Каждый mongod раз в секунду пишет свои метрики в diagnostic.data, но на Atlas M10 под боевой нагрузкой эти файлы живут два-пять дней. mongo-health хранит их три месяца, раз в час прогоняет 68 проверок и даёт один вердикт по кластеру. В примерах: запрос без индекса читал около 10 миллионов документов на каждый возвращённый. Percona сама пишет, что это не замена мониторингу: читает раз в час и никого не будит.

Grafana Labs 19 октября отчиталась, как улучшала самого Assistant: за примерно 10 недель доля ошибок в режиме дашбордов упала с 2,47 % до 0,65 %, задержка по 95-му перцентилю с 63 до 28,8 секунды, стоимость запроса на 18 %.

Зачем это бизнесу с одним сервером

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

Вывод тот же: историю нужно хранить дольше, чем вы соберётесь её смотреть, и первым вопросом будет «что изменилось перед этим». Агенту-расследователю нужны те же записи, что и вам, и без них он тоже ничего не найдёт.

Как это устроено у меня

У PDR-компании в США я с 2021 года технический партнёр, и инфраструктуру мониторю сам: сервер на Debian в Google Cloud, MariaDB, VPN, телефония на собственной PBX. С 2022 года, когда появился свой сервер, серьёзных сбоев с восстановлением не было.

На гидропонной ферме, с которой я работаю с 2023 года, в одной сети 25 контроллеров на 2 площадках, сервер на Debian в Google Cloud и база MariaDB. Активной разработки с моей стороны сейчас нет, а поддержка довольно активная: обновления, отладка, разбор проблем, когда они появляются. Здесь мне и нужен дежурный, который ночью соберёт контекст.

AI помогает мне с тестированием и отладкой, результат я проверяю. Автоматическое «предложенное исправление» в духе Managed Sandboxes я бы принял только с доказательствами: какие метрики на это указывают и что изменилось перед сбоем. И с правом вето: на сервер изменение попадает через тот же порядок проверок, что и любое другое.

Что я бы сделал

Хранить историю дольше умолчаний. Метрики и логи за несколько недель.

Вести журнал изменений: когда что выкатили и какой конфиг поменяли. В замере CNCF история изменений была вторым запросом агента на 35 сбоях из 50. Без неё и человек, и агент тратят время на реконструкцию.

Начать с одного сервиса и доступа только на чтение. Дать агенту метрики, логи и журнал изменений, попросить найти причину прошлого инцидента и сравнить с тем, что нашли вы.

Предложенное исправление принимать как pull request с доказательствами, а выкатывать руками через обычные проверки.

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

Связанные материалы

О сервере как центре системы я писал в статье Сервер: данные, доступ и выполнение процесса. Направление: инфраструктура, которую можно выпускать и восстанавливать. Кейсы: технический партнёр PDR-компании с 2021 года и гидропонная ферма с 25 контроллерами. Из других обзоров: сколько наблюдаемости нужно системе на одном сервере, бэкап, который никто не восстанавливал и что я разрешаю AI-агенту на боевом сервере. Раньше я писал о графе наблюдаемости и проверяемых гипотезах. Если у вас есть сервер, за которым никто не следит ночью, расскажите, что на нём работает и как вы узнаёте о проблемах сейчас. Обсудить задачу.