"AgenticOps, часть №4 - агенты и сценарии Тут расскажу про основных агентов, которые пользуются платформой - у них разные роли и доступные сценарии. Роль агента приходит как внешний по отношению к CLI параметр (через конфиг или переменную окружения) и, по сути, ограничивает список доступных агенту команд в определённом контексте. Т.е. агент ещё на этапе discovery видит только те команды, которые ему можно вызывать, а потом ещё и платформа эти доступы проверяет. Агент-разработчик приложения Это вот Codex / Claude Code, с которым непосредственно я сам работаю в контексте конкретного приложения. Ему, помимо прочего, скиллом вменяется политика того, как правильно работать с платформой: как, к примеру, логировать и добавлять трейсинг в код приложения. Возможности, которые даёт платформа: ● получить актуальную топологию и версии задеплоенных компонентов приложения ● узнать как идёт билд/деплой, триггернуть по необходимости ● получить отфильтрованные логи/трейсы со всех deployment units системы ● получить быстрый срез здоровья всей системы через запрос диагностического бандла ● залезть read-only в базу/redis/rabbitmq/etc ● создать/прочитать таски в таск-трекере Примеры того, как агент этим пользуется: ● трейсы помогают понять, где сломался многошаговый процесс, затрагивающий несколько разных сервисов, получить связанные логи, опросить БД, очереди и т.п. ● агент сам придумывает и дебажит смоук- и e2e-тесты, держа под контролем не только ""видимый"" результат, но и то, что происходит внутри системы ● знание топологии помогает агенту лучше понимать системную архитектуру, писать совместимый код и предлагать изменения инфры В итоге, чаще всего баги чинятся так: кинуть скриншот в чат с сообщением об ошибке и URL'ом, а в конце просто проверить, что оно уже работает, после деплоя на нужном окружении. Даже если от агента это потребовало прошерстить несколько связанных сервисов на бекенде, придумать e2e-тест на всю цепочку и отладить его. Агент-оператор платформы ● владеет дескрипторами и инфраструктурными ресурсами, которые выданы конкретному приложению ● создаёт базы, бакеты, пользователей, выдаёт доступы к инструментам, которыми потом будет пользоваться агент-разработчик приложения ● может перетаскивать существующие приложения на платформу, создавая все необходимые ресурсы ● поднимает новые окружения, включая временные, которые потом так же удаляет (это, кстати, переедет к агенту приложения - удобно под большие фичи отдельные окружения заводить) Агент-разработчик платформы ● управляет кодом платформы и может любой из сервисов добавить/поменять ● что при этом важно - он знает, какие из приложений и какие их ресурсы попадут в blast radius, потому что ему доступно состояние их инфраструктуры ● за счёт того, что все конфиги платформы, все адреса - в коде, и есть доступ ко всем компонентам и их телеметрии - может сам дебажить проблемы по всей инфре ● может интегрировать и увязать с существующими какой-то новый инфраструктурный компонент Агент-деплоер ● использую как субагент стандартного workflow разработки, последним шагом ● если что-то фатально отвалилось - собирает диагностику и передает управление основному агенту с вменяемым описанием проблемы Агент-монитор Шедулится на 24/7 машине и следит за логами, алертами по расходу ресурсов и т.п. - мелочи фиксит сам и делает PR в Gitea, для более сложных - собирает более полную диагностику и заводит баги в таск-трекере со ссылками на спаны/логи/etc Break-glass путь Если случается какой-то дизастер/непреодолимое препятствие, можно переключиться на прямой доступ к серверам. Для этого есть отдельный набор инструкций - где что брать и как подключаться, который хранится отдельно и выдается агенту по необходимости. — В целом, роли агентов ограничиваются лишь фантазией, нарезать можно как угодно. Главное, что у них есть набор детерминированных и безопасных инструментов по работе с инфраструктурой и все это гибко настраивается и легко развивается. В том числе за счёт того, что агенты сами эти дорожки протаптывают, но об этом в следующий раз :) #ai #agentic_ops #devops"