Руководство
Как использовать AI-инструменты для поиска ошибок и ускорения релизов
Обновлено · 6 мин чтения
AI-агент ускоряет поиск ошибок, когда читает логи сборки и приложения, воспроизводит сбой тестом, предлагает исправление и следит за выкаткой. Человек остаётся там, где шаг необратим: удаление, секреты, рабочие данные и слияние в рабочую ветку. Ниже шесть шагов процесса и инструменты MCP-сервера DADA Cloud, которые закрывают его со стороны платформы.
Шаг 1 - Подключите агента с минимальными правами
Внешний агент (Claude Code, Claude Desktop и другие клиенты) управляет платформой через MCP-сервер. Команды подключения и порядок входа описаны в руководстве про AI-агентов на DADA Cloud и на странице MCP. Важное для безопасности: агент действует от вашего имени и с вашей ролью. Для работы только с диагностикой подключайте его под участником проекта с ролью ReadOnly, для исправлений хватит Developer.
Платформа ограничивает и сам набор инструментов. Всего их 63, из них 27 только читают данные и 5 помечены как разрушающие. Инструментов для удаления приложений, баз данных и проектов, для перезапуска у агента нет. Значения секретных переменных он тоже прочитать не может: listEnvVars их маскирует.
Шаг 2 - Дайте агенту прочитать сбой
Хороший разбор начинается с чтения, без правок. Вот инструменты, которые для этого нужны:
| Задача | Инструмент | Что получает агент |
|---|---|---|
| Найти проект и приложение | resolveRef, listProjects | Идентификаторы по именам, UUID знать не нужно |
| Узнать состояние | listApps | Фазу приложения, например Healthy |
| Понять, почему упала сборка | getBuild | Состояние сборки |
| Прочитать логи выполнения | searchLogs | Строки логов по приложению, запросу и периоду |
| Проверить запись изменения | getOperation | Статус Committed: изменение записано в git |
| Запустить сборку | triggerBuild | Идентификатор сборки |
Порядок для сбоя такой. Сначала listApps: приложение вообще живо? Потом searchLogs за последний час, затем с запросом error за шесть часов. Если похоже на проблему сборки, getBuild. Две ловушки. Статус Committed означает, что изменение записано в git, но не обязательно запущено: до окончания выкатки смотрите фазу в listApps. И triggerBuild возвращает идентификатор сборки, ход сборки отслеживайте по нему через getBuild: getOperation для этого не подходит. Готовый рецепт диагностики лежит в рецептах MCP, полный список инструментов в справочнике.
Шаг 3 - Воспроизведите ошибку
Попросите агента сначала написать падающий тест или минимальный скрипт по строкам лога и только потом чинить. Это отсекает правки наугад: если ошибку не удалось воспроизвести, исправление остаётся догадкой.
Запускать можно у себя на машине. Если нужна изолированная среда с правами root, подойдёт Box: временная среда на Ubuntu 24.04 с node, python, go, rust и psql, без Docker. Максимальный срок жизни 8 часов, лимит расходов по умолчанию 500 рублей. Когда срок или лимит исчерпаны, среда засыпает или приостанавливается, но не удаляется. Это песочница для экспериментов, копией вашего окружения она не является, подробности на странице Box. Секреты рабочего окружения в неё не переносите.
Чтобы посмотреть состояние данных, у агента есть queryDatabase: только SELECT, до 1000 строк, 5 МБ и 5 секунд, а explainDatabaseQuery показывает план запроса. Эти запросы читают рабочие данные, поэтому заранее решите, что агент вправе увидеть. Если в таблицах персональные данные, дайте ему выборку без них.
Шаг 4 - Исправьте и проверьте до выкатки
Агент вносит правку в отдельной ветке, запускает тесты и открывает pull request. Дифф читает человек. У платформы нет превью-окружений для pull request, а окружение в проекте одно, поэтому единственная проверка до выкатки это CI и ваш локальный запуск. Слияние в рабочую ветку при включённом автодеплое и есть релиз, поэтому защитите эту ветку на стороне GitHub: слияние только после ревью и зелёных проверок.
Если исправление требует миграции схемы, делайте её совместимой с прошлой версией кода: сначала добавьте, затем удалите. Тогда откат остаётся безопасным. Перед выкаткой такого изменения снимите копию базы в консоли, об этом руководство про резервное копирование.
Шаг 5 - Выпустите и понаблюдайте
После слияния сборка стартует сама, если автодеплой включён. Если выключен, агент вызывает triggerBuild. Для приложения из образа он вызывает updateAppImage с новым тегом и ждёт getOperation до Committed. Дальше цикл один и тот же: getBuild до завершения сборки, listApps до фазы Healthy, searchLogs с момента выкатки.
Задайте агенту условие завершения заранее: приложение в Healthy, исходная ошибка из шага 2 пропала из логов, исходный запрос отрабатывает. Если условие не выполнено, агент не продолжает правки сам, а возвращает вам отчёт. Общий порядок деплоя описан в руководстве как развернуть веб-приложение.
Шаг 6 - Подготовьте откат и оставьте человеку необратимое
Откат контейнерного приложения выполняется в консоли на вкладке выкатов или через API выкаток: платформа возвращает прошлый образ без пересборки. Инструмент rollbackApp в MCP относится к приложениям на собственном сервере. Если приложение развёрнуто из образа, агент может указать прежний тег через updateAppImage. Для приложений из git откат лучше оставить за собой.
Человеку остаются:
- удаление приложений, баз и проектов: этих инструментов у агента нет;
- секреты: значение вводите вы, агенту можно поручить
setEnvVarс флагомis_secret=true, но не диктовать ключи в чате; - рабочие данные: выдача учётных данных базы записывается в аудит, запросы читают реальные строки;
- привязка домена к приложению, резервные копии и восстановление баз: это шаги консоли;
- слияние в рабочую ветку.
Чек-лист безопасной автоматизации
- Роль агента соответствует задаче: ReadOnly для диагностики, Developer для правок.
- Рабочая ветка защищена: ревью и успешный CI обязательны.
- Перед миграцией снята копия базы, сама миграция обратима.
- Агент заканчивает работу, когда приложение Healthy и логи чистые. Статуса Committed для этого мало.
- Секреты не попадают в промпты, коммиты и логи.
- Число попыток «исправить и выкатить» ограничено, например тремя, после чего агент зовёт человека.
- Удаления и откат контейнерных приложений выполняет человек.
Частые вопросы
Может ли агент сам выкатить исправление на рабочее окружение?
Технически да: через triggerBuild или updateAppImage после его слияния. Но слияние в рабочую ветку лучше оставить за человеком, потому что при включённом автодеплое оно и есть релиз.
Что агент не сможет сделать с моей инфраструктурой?
Удалить приложение, базу или проект, перезапустить сервис, выполнить команду на сервере, прочитать значения секретных переменных, привязать домен к приложению. Запросы к базе только на чтение.
Нужен ли отдельный стенд для проверки правок агента?
Превью-окружений нет, окружение в проекте одно. Проверяйте правки тестами в CI и локальным запуском. Box подходит для экспериментов, но не воспроизводит ваше окружение.
Как отозвать доступ агента?
Если он подключён от вашего имени, удалите коннектор или плагин в клиенте. Служебные идентичности получают доступ через временные гранты, порядок описан в руководстве про AI-агентов.
Сколько инструментов у MCP-сервера?
63: 27 только читают данные, 5 помечены как разрушающие. Число закреплено тестом в коде платформы.