Infrastructure as Code научила нас важной дисциплине: инфраструктура не должна жить только в голове. Ресурсы, настройки и изменения надо описывать, хранить в Git, применять повторяемо и обсуждать как код.
Это все еще правильная мысль. Terraform хорошо описывает ресурсы. Ansible хорошо описывает действия. CI/CD хорошо описывает путь изменения от репозитория до рабочей среды. Мониторинг хорошо ловит симптомы.
Но когда в эксплуатацию входит ИИ-агент, появляется новый вопрос: что агент должен понимать перед действием?
Не какую команду выполнить. Не какой ресурс создать. Не какой playbook применить. А именно понимать: куда он попал, что здесь считается правдой, что уже проверено, что только предполагается, какие решения нельзя повторять, какие секреты нельзя читать, что обязательно записать после изменения.
Я называю этот слой AgentOps.
Это не замена всем старым практикам. Это слой над ними. Если инфраструктура теперь обслуживается агентом, ей нужна не только автоматизация, но и контекст, рассчитанный на агента.
Что не закрывает IaC
У IaC есть сильная сторона: он фиксирует намерение.
Terraform говорит: такие ресурсы должны существовать. Ansible говорит: такие задачи должны быть применены. CI/CD говорит: изменение должно пройти такой путь.
Но живая эксплуатация шире намерения.
В моей личной инфраструктуре есть домашний Proxmox, OpenWrt, виртуальные машины, Docker-сервисы, публичные VPS, боты, маршрутизация, удаленные серверы, временные обходы и решения, принятые после реальных инцидентов. Часть этого можно описать кодом. Часть лучше проверять живыми командами. Часть важна не как состояние, а как причина.
Например, можно описать новую VM в Proxmox. Но агенту все равно нужно знать, какие сетевые мосты используются, какие виртуальные машины уже есть, какой контур считается домашним, какие старые маршруты больше не стоит повторять.
Можно написать Ansible-задачу для службы на VPS. Но агенту нужно знать, где рабочий путь, какие порты исторически удалены, какие секреты нельзя читать, какая проверка считается достаточной, что поменялось в прошлый раз.
IaC отвечает на вопрос “что применить”. AgentOps отвечает на вопрос “из какого контекста действовать”.
Как выглядит AgentOps в моей системе
Моя текущая реализация простая: ops-hub как рабочая память инфраструктуры.
В корне есть README.md, AGENTS.md, decisions.md и папки машин или контуров: home/, vps-5-129/, vps-65-108/.
home/ - это домашний контур: мини-ПК, Proxmox, OpenWrt, виртуальные машины и локальные сервисы. vps-* - отдельные публичные серверы. Retired-серверы остаются отдельными историческими записями, а не смешиваются с активными.
Это важно: карта совпадает с реальностью. Не проект, не абстрактная область, не архивная полка, а место эксплуатации.
В каждой серверной папке четыре файла:
-
current.md- состояние; -
services.md- службы; -
log.md- действия; -
runbook.md- проверки.
current.md говорит, что это за сервер сейчас: роль, адреса, ограничения, что подтверждено живой проверкой, что пока предполагается.
services.md говорит, что на нем работает: службы, порты, контейнеры, пути, домены, зависимости, важные systemd units.
log.md говорит, что с ним делали: короткие записи без простыней команд.
runbook.md говорит, как с ним работать: как зайти, что проверить, как восстановить, где нельзя сохранять секреты.
Это не просто документация. Это интерфейс между агентом и инфраструктурой.
Зачем здесь AGENTS.md и skills
AgentOps не держится только на четырех файлах.
AGENTS.md задает правила поведения. Перед серверным действием агент должен прочитать контекст. После действия - обновить память. Если изменились службы, порты, пути, контейнеры или процедура, это должно попасть в соответствующие файлы. Если доступ требует пароль, которого нет в сессии, агент не должен угадывать.
Это похоже на guardrails, но не в смысле запретов ради запретов. Это эксплуатационная дисциплина. Агент может быть сильным, но сила без памяти превращает инфраструктуру в черный ящик после каждого изменения.
Скилы добавляют повторяемые процедуры. Они могут описывать, как развернуть конкретный тип сервиса, как провести аудит Proxmox, как проверить OpenWrt-контур, как работать с медиа-стеком. Но skills не должны быть единственным источником правды. Они дают навык. ops-hub дает контекст, где этот навык применять.
Вместе получается рабочая среда:
-
карта машин;
-
правила агента;
-
память серверов;
-
процедуры через skills;
-
история решений.
Это и есть минимальная форма AgentOps.
Цикл вместо разового выполнения
В классической автоматизации легко мыслить шагами: применить конфиг, выполнить роль, создать ресурс.
В AgentOps важнее цикл:
-
понять контекст;
-
проверить реальность;
-
сделать минимальное изменение;
-
проверить результат;
-
обновить память.
Последний шаг принципиален. Если агент выполнил команду, но не обновил память, он сделал только половину работы. Сервер изменился, а карта осталась старой. Следующий заход снова начнется с расследования.
Если агент создал VM, в памяти должно появиться, зачем она нужна, где она находится, как ее проверить. Если агент удалил контейнер, журнал должен сказать, что удалено и чем подтверждено. Если агент не смог проверить узел из-за доступа, это тоже факт, который надо записать.
Так появляется повторяемость другого типа. Не только “запусти один и тот же playbook сколько угодно раз”, а “каждый раз сравни ожидание с реальностью, сделай только дельту и обнови карту”.
Для личной инфраструктуры это часто практичнее.
Ночная рефлексия
Следующий шаг - ночная рефлексия.
Днем агент помогает с задачами. Ночью он может проходить по серверным папкам, читать runbook.md, выполнять безопасные проверки и сверять документы с реальностью.
Не чинить все подряд без разрешения. А именно сверять.
Служба описана как рабочая, но упала. Контейнер исчез. Порт изменился. Путь устарел. Сервер недоступен по SSH. Предположение удалось подтвердить живой командой.
Так документы перестают быть снимком прошлого. Они становятся картой, которая регулярно сверяется с реальностью.
Это особенно важно сейчас, когда многие дают агентам широкий доступ к коду и серверам. Включить permissive mode легко. Но широкий доступ без памяти - это сильный исполнитель без передачи смены. AgentOps добавляет вторую половину: не только право действовать, но и обязанность поддерживать контекст.
Почему это новая категория
AgentOps связывает это вокруг агента: где он находится, чему верить, что можно менять, что проверить и что оставить после себя.
Для большой инфраструктуры все старые инструменты остаются нужными. Для личной инфраструктуры и маленьких команд AgentOps может стать центральной моделью: меньше идеальной формализации, больше живого контекста, меньше “куда положить документ”, больше “что должен знать следующий агент”.
Автор: iAlexeyRu
