Grafana показывала, что горит, Mattermost доставлял уведомления, но после смены дежурного приходилось заново выяснять, кто занимается проблемой и когда ждать результат. Рассказываю, как мы собрали поверх них рабочее место с владельцами, ETA, общей историей, группировкой каскадных алертов, инцидентами и postmortem — без отдельной базы данных и без передачи управления состоянием LLM.
Разработчикам регулярно требовались виртуальные машины, но self-service не существовал. Образ, ресурсы, сеть и доступы настраивала инфраструктурная команда. По отдельности операции были несложными, но в сумме пользователи ждали, а инженерное время уходило на повторяемую ручную работу.
Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.
В статье показано как на базе KubeVirt получился цельный внутренний продукт с минимальными трудозатратами, в котором разработчик действует самостоятельно, а платформа сохраняет контроль над dev-контуром и блокирует создание VM сверх бюджета команды.
Я делаю внутреннего read-only LLM-агента для инфраструктурных расследований. Инженер задаёт вопрос обычным языком, а агент собирает доказательства из Kubernetes, метрик, логов, GitLab, Grafana и других эксплуатационных источников.
Один реальный кейс показал, почему «умного промпта» недостаточно: edge вернул 502, хотя приложение для того же request_id записало успешный редирект 302. Чтобы найти причину и не придумать удобное объяснение, агенту пришлось научиться связывать источники, удерживать время и scope, различать факты, гипотезы и отсутствующие данные.
В статье разбираю архитектуру агента на Go, DeepSeek, Qwen и MCP: планирование по evidence, контракты tools, память треда, подключение командных skills через n8n и evaluation на реальных сценариях. В последнем полном прогоне прошли 44 из 45 сценариев, включая все 29 обязательных.