Автоматизация правок на боевых сайтах: как ИИ-агент работает с SSH и файлами
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Команда разработчиков описала процесс интеграции ИИ-агента в управление боевыми сайтами на MODX, где агент получает права на запись через SSH и специализированный файловый инструмент. Ключевыми задачами стали защита от блокировок хостингом, предотвращение конфликтов параллельных операций и обеспечение атомарности изменений с автоматическим откатом при ошибках.
Материал демонстрирует практические инженерные решения для безопасного внедрения автономных ИИ-агентов в production-среду, включая управление соединениями, контроль доступа к чувствительным файлам и механизмы блокировок, что критически важно для снижения рисков при автоматизации DevOps-процессов.
В продолжение предыдущего описания работы с CMS MODX через MCP-интерфейс, команда разработчиков детализирует этап предоставления ИИ-агенту прав на запись в боевые системы. Если ранее агент мог лишь анализировать структуру сайта и предлагать решения, то теперь он способен самостоятельно выполнять исправления, проверять их работоспособность и откатывать изменения при сбоях. Основной целью было исключить ручное вмешательство разработчика в рутинные операции: подключение по SSH, резервное копирование, загрузку файлов и проверку синтаксиса кода.
Первым серьезным препятствием стала работа с SSH. В отличие от человека, который держит соединение открытым длительное время, ИИ-агент генерирует множество коротких последовательных подключений для чтения логов, проверки версий PHP и выполнения диагностических команд. На одном из хостингов это привело к частым блокировкам IP-адреса из-за превышения лимита соединений. Поскольку добавить адрес в белый список было невозможно, разработчики реализовали обертку над OpenSSH. Она использует механизм ControlMaster для переиспользования одного TCP-соединения при выполнении десятков команд, а также применяет файловые блокировки (flock) для предотвращения гонок при создании основного канала. Параллельность выполнения команд на один аккаунт была ограничена до двух-восьми процессов в зависимости от нагрузки хостинга.
Для работы с физическими файлами был создан отдельный инструмент site-file, так как стандартная SSH-оболочка не является песочницей и позволяет агенту использовать любые утилиты для записи. Инструмент реализует строгий контроль путей: попытки выхода за пределы корня сайта через «..» или доступ к системным директориям (.ssh, .git) блокируются на уровне нормализации пути. Чувствительные файлы, такие как .env, config.core.php и ключи, исключены из доступа даже для чтения. Изменения в критические файлы (index.php, .htaccess) требуют явного флага разрешения.
Процесс записи файлов построен по принципу «сначала просмотр, потом применение». Без флага --yes инструмент лишь показывает разницу между текущей версией на сервере и предлагаемой, вычисляя контрольные суммы SHA-256. При подтверждении изменения сначала сохраняется резервная копия предыдущей версии с метаданными. Само написание данных выполняется через временный файл в том же каталоге, который затем атомарно переименовывается в целевой, что исключает риск получения поврежденного файла при обрыве соединения.
После записи система автоматически выполняет проверку: контрольная сумма нового файла сверяется с ожидаемой, для PHP-файлов запускается php -l, а также проверяется доступность указанной страницы. Если любой из этапов завершается ошибкой, предыдущая версия файла восстанавливается автоматически. Это снимает с разработчика необходимость вручную отслеживать целостность кода после каждого изменения.
При одновременной работе нескольких агентов над одним сайтом возникает риск конфликта версий: один процесс может перезаписать изменения другого, основываясь на устаревших данных. Для решения этой проблемы внедрена глобальная блокировка проекта (project.lock). Она фиксирует PID процесса и boot_id сервера. Если процесс завершается аварийно или сервер перезагружается, блокировка автоматически признается недействительной по истечении короткого таймаута или при смене идентификатора загрузки системы. Живые блокировки нельзя снять штатными средствами, что предотвращает случайное удаление защиты настойчивым агентом.
Таким образом, система обеспечивает безопасную среду для автономных правок: транспортные проблемы решены через оптимизацию SSH, логические ошибки предотвращены механизмами атомарности и отката, а конфликты параллельных задач — централизованными блокировками. Источник: web:Habr AI — https://habr.com/ru/articles/1090118/