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
Тут расскажу про основных агентов, которые пользуются платформой - у них разные роли и доступные сценарии.
Роль агента приходит как внешний по отношению к 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