DevOps-лид открыл nib: агент раскладывает деплой в AWS на этапы, проверки и откат

«Разверни новый веб-сервис в AWS и сделай джобы для деплоя». Одна строка в трекере. А за ней сеть, контейнеры, база, секреты, CDN, два workflow и десятки мелких действий, которые инженер держит в голове. Пока вас никто не отвлекает, это работает. Но после созвона уже непонятно, закрыли ли вы порт базы, а на вопрос «сколько займёт» остаётся честное «день-два».

Автор разбора — руководитель DevOps-команды в игровой студии с 15-летним стажем. Он формализовал свой способ планирования и отдал его агенту под названием nib (Neuro Infrastructure Builder).

Как планирует опытный инженер

Сначала собирается контекст: что за проект, как устроена текущая инфраструктура, что известно о продуктах из задачи. Затем задача делится на крупные этапы: код инфраструктуры, build- и deploy-workflow, создание ресурсов, деплой, проверка. Важнее самого списка зависимости между этапами, они определяют, что можно делать параллельно.

Каждый этап раскладывается на элементарные действия: поправить файл, выполнить команду, сделать API-вызов. К каждому действию нужны проверка и откат. Например, после terraform plan в diff не должно быть ни одного destroy, а после apply RDS должна быть в статусе available. Колонку «Откат» чаще всего оставляют пустой. Автор спрашивает: когда вы в последний раз писали план отката до того, как он понадобился?

Процесс ломается в трёх местах. Пункты выпадают из головы при переключении контекста: автор однажды перенёс бакеты с ассетами между облаками и забыл про CORS. Проверки режут под дедлайн, потому что их пропуск ничего не ломает сразу. И нет оценки объёма: пока задача не разложена, «день-два» не оценка, а ощущение.

Что делает nib

Инструмент работает в трёх режимах. Decompose задаёт уточняющие вопросы и выделяет этапы с зависимостями. Plan запускает по агенту на каждый этап, они параллельно расписывают действия и проверки, а отдельный агент строит откат. Execute выполняет действие через подключённые инструменты либо даёт оператору подробную инструкцию.

Контекст инженера заменяет база знаний: описание компании, VCS, CI/CD, схема сетей, соглашения об именовании. После завершения плана nib пишет отчёт и обновляет базу, так что следующая задача стартует с тем, что агент узнал в прошлой.

Установка локальная: git clone, make setup, Docker и ключ любого OpenAI-совместимого провайдера. Инструменты подключаются через MCP по HTTP-транспорту: GitHub, AWS API и SearXNG для поиска документации. AWS-сервер отдаёт всего два инструмента (вызов CLI и помощник по командам), GitHub — пару десятков. Чтобы не раздувать контекст, nib на этапе декомпозиции выбирает только нужные категории инструментов.

Где легко обжечься

Настройки безопасности в примере щедрые. READ_OPERATIONS_ONLY: false разрешает изменения, а REQUIRE_MUTATION_CONSENT: false убирает подтверждение на стороне MCP-сервера. Подтверждением остаётся кнопка Execute в самом nib. AUTH_TYPE: no-auth допустим только потому, что порт не опубликован наружу, а сервис виден лишь внутри docker-сети.

Секреты лежат в двух местах. Ключи AWS нужны контейнеру aws-mcp, поэтому они в .env. Токен GitHub передаётся заголовком от nib к MCP-серверу и хранится в секретах nib с белым списком хостов. Для GitHub нужен classic-токен со scope repo и workflow, без второго агент не сможет закоммитить файлы в .github/workflows.

Практический вывод

Главная ценность здесь не в магии агента, а в самой дисциплине: действие, проверка, откат на каждом шаге. Даже без nib эту таблицу стоит писать до начала работы, а оценка по числу действий честнее «дня-двух». Если пробуете инструмент, берите отдельный песочничный аккаунт AWS и не давайте агенту прав шире нужных. Эта часть охватывает только базу знаний, правила и навыки автор обещает разобрать в следующей статье.