Метрика сообщает факт: диск заполнен, процессор загружен, машина не выходит на связь. Дальше начинается работа, которую обычно делает инженер, — превратить факт в гипотезы и проверить их по одной. Именно здесь агент экономит больше всего времени, и именно здесь он безопаснее всего: диагностика не меняет систему.
Превратите сигнал в вопросы
Хороший запрос к агенту содержит не только симптом, но и контекст. Разница видна сразу: «диск заполнен» даёт общий ответ, «системный диск заполнился с 40% до 95% за трое суток, машина — рабочее место бухгалтера, обновлений не ставили» даёт список конкретных мест, куда смотреть.
- Добавляйте динамику, а не только текущее значение: скорость изменения информативнее уровня.
- Указывайте назначение машины. Норма для терминала с базой и для рабочего места разная.
- Сообщайте, что менялось перед появлением симптома — обновление, новая программа, переезд в другую сеть.
- Просите не ответ, а ранжированные гипотезы с проверкой для каждой. Так вы получаете план, который можно выполнить и опровергнуть.
Правило двух подтверждений
Одно правдоподобное объяснение — не диагноз. Прежде чем что-то менять, найдите второй независимый признак, подтверждающий гипотезу.
Например: гипотеза «диск забит журналами приложения» подтверждается размером каталога и датами файлов, а не только тем, что такое бывает часто. Если второго подтверждения нет, вернитесь к списку гипотез, а не приступайте к действиям.
Это правило особенно важно потому, что модель почти никогда не отвечает «не знаю» — она формулирует уверенно даже там, где данных недостаточно.
Держите диагностику в режиме чтения
Вся описанная работа не требует прав на изменение: чтение метрик, журналов и списка процессов. Оставляйте агента в режиме просмотра на этом этапе — тогда его можно применять к любой машине без отдельного решения по каждой. Метрики, доступные для контекста, перечислены на странице мониторинга парка, а сама модель разграничения — на странице GoDesk AI.
Какие пороги вообще дают полезные сигналы, а какие создают шум, разобрано в статье о порогах CPU, памяти и диска.
Что делать, если модель уверенно называет неверную причину?
Относиться к её ответу как к гипотезе, а не к диагнозу, — и проверять его тем же способом, каким проверяли бы догадку коллеги. Уверенный тон здесь ничего не значит: он одинаков и для верного ответа, и для неверного, поэтому решает проверка, а не формулировка.
Стоит ли отдавать модели логи с рабочих машин?
Только после того, как вы понимаете, что в этих логах есть. Системные журналы регулярно содержат имена пользователей, пути к файлам и адреса внутренних сервисов — это не секреты по отдельности, но вместе они описывают вашу инфраструктуру подробнее, чем хотелось бы.