Идея проекта: платформа для сисадмин/SRE/DevSecOps агентов, с акцентом на нужды организаций, которые стараются сами хостить и управлять свои ИТ-системы (self-hosted).
Сейчас уже довольно понятно, что эти задачи должны решаться взаимодействующей командой агентов, каждый из которых заточен на более узкие задачи, например,
- Маппинг сервисов и настройка сетей
- Аудит безопасности, патчинг, и поддержка (напр., key rotation)
- Мониторинг ресурсов и боттлнеков, оптимизация размещения сервисов на текущем флоте машин, планирование расширений (если требуется)
- Локализация и траблшутинг деградаций
- Планирование и проведение апгрейдов и даунгрейдов
Я еще не смотрел очень близко на autogen, swarms и другие опен-сорсные “платформы для команд/роев/обществ агентов”, не знаю, насколько их можно прям брать и просто добавлять к ним что-то сверху, типа пакета стандартных инструментов для работы с консолью и т.д. Может быть, можно, а может, нужно велосипедить именно отдельный фреймворк, хотя и с использованием идей из autogen, swarms, OpenDevin, и других подобных проектов.
Также, как вы можете заметить, я делаю ставку на то, что функции сисадмин/SRE/DevSecOps/инженеров ИТ-платформ слишком разнообразны, чтобы быть впихнутыми в “единого” агента типа OpenDevin для программирования. Строго говоря, это относится и к программированию, потому что там интересы безопасности тоже должны быть явно учтены даже на уровне отдельных пулл-реквестов, но там пока достаточно проблем для решения на более низких уровнях, а именно, собственно программирование, поиск и исправление прямых багов в коде, и т. д. Поэтому, скорее, это агент-программист типа OpenDevin должен быть одним из команды агентов, перечисленных выше. Например, в случае, если надо срочно обновить библиотеку с 0-day уязвимостью, но так как она давно не обновлялась, это обновление ломает код нашей системы (или одной из библиотек “посередине”). И тогда агент-программист должен срочно поправить и собрать новую версию кода нашей системы.
Еще одно отличие: у агентов-программистов есть очевидно один “победивший” способ управлять изменениями, а именно коммиты в систему контроля версий, пулл-реквесты, и обсуждения к ним. Поэтому агентам-программистам типа OpenDevin не надо изобретать велосипед для governance и аудита: они могут дампить цепочку своих рассуждений в описание пулл-реквестов.
В сисадминстве/SRE/DevSecOps же, такое возможно только в случае 100% покрытия infrastructure-as-code и configuration-as-code + monorepo, чего нет вообще нигде, особенно в развесистых self-hosted сетапах. Попытки натянуть сову на глобус в этом случае могут добавить очень большой слой боилерплейта через который люди уже совсем ничего не увидят. Поэтому, в командах сисадмин/SRE/DevSecOps агентов нужен более неформальный подход к audit trail и governance.
