Я пустил ИИ-агента на рабочий кластер 1С. Он нашёл 119 ГБ srvinfo, бэкап-призрак и не нашёл тормозов

«Утром никто не может зайти: 1С-ка глючит». «Пользователь ушёл домой ещё вчера, а его сеанс до сих пор висит и держит лицензию». «rphost опять съел всю память, перезагружаем сервер, как каждую неделю». Если вы хоть раз администрировали 1С, у вас сейчас дёрнулся глаз. У меня тоже дёргался, пока я собирал эти фразы с форумов. Причём не те, что красиво смотрятся в презентации, а те, что люди пишут годами, и с каждым разом всё злее.

А потом я сделал то, от чего у любого безопасника поднимется давление: посадил ИИ-агента за большой рабочий кластер. Без RDP, из обычного чата. В тестовую базу, не паникуйте, но кластер настоящий: 16 баз, два сервера, 512 ГБ памяти. Пятнадцать минут диагностики, тринадцать минут разработки. Ниже протокол без купюр: что агент нашёл, где споткнулся, чего я ему не разрешил и что пока не проверял.

Честно сразу: инструмент, через который агент лез на сервер, мой. Называется Local Commander, выполняет команды ИИ на Windows-машинах. Так что если вам покажется, что я его хвалю, дочитайте до раздела про то, что в нём надо чинить. Он длинный.

Глаза есть, рук нет

1С-ники сейчас вовсю строят себе ИИ-разработку, и это видно по Инфостарту: MCP-серверы для 1С, связки «Cursor + MCP + выгрузка конфигурации», красота. Но почти всё это живёт на машине разработчика. Агенту показывают метаданные, синтаксис, выгруженный код, то есть дают глаза. А сервер, где реально живёт база и где реально что-то горит, остаётся за стеклом.

Гипотеза была простая: дай агенту руки там, где стоит база, и он полезет не только в код, но и в эксплуатацию. Сначала я был уверен, что главный козырь — «программисту больше не нужен RDP». Пошёл на форумы проверять и нашёл ровно одну заметную ветку. Боль оказалась моей, а не вашей. Зато сеансы, лицензии, раздутые журналы, кэш, бэкапы и вечное «1С тормозит» всплывают годами. Туда я и нацелился.

Стенд и правила

Субботний вечер, 17 октября. Стенд без бутафории:

• тестовая копия рабочей базы 1С:Управление холдингом 3.2.6.85, платформа 8.3.27;

• MS SQL Server, файл данных около 70 ГБ;

• сервер базы: Windows Server 2022, 64 логических ядра, 512 ГБ памяти;

• кластер на 16 баз, рабочие процессы на двух серверах.

На сервер базы я не поставил ничего. Агент жил на соседней машине с Windows Server 2022 в той же сети и работал оттуда.

Задание уместилось в одно сообщение: реквизиты, список ситуаций из жизни админа и структура отчёта. Плюс пять правил, которые я дал бы любому новичку на чужом сервере. Менять только тестовую базу, остальные смотреть, держа руки за спиной. Код только в расширении, основную конфигурацию не трогать. Перед любым изменением сначала план и моё «давай». Службы и кэш кластера только в окно обслуживания. Пароли не светить нигде. Запомните одну деталь: эти правила соблюдала модель, а не инструмент. Мы к этому ещё вернёмся.

Минута первая: RAC молчит

23:04, агент осматривается и ищет базу. 23:05, первая стена: RAC на 1545 не отвечает. Живой админ в этот момент вздыхает и идёт искать, кто закрыл порт и зачем. Агент молча переключился на COM-интерфейс кластера через 1540 и следующие пять минут спокойно читал кластер, сеансы, лицензии и расширения.

С лицензиями случился момент, на котором я выдохнул. Четыре сеанса, у одного клиентская лицензия на 10 пользователей. Агент не написал «занято 10 лицензий». Он понял, что десятка — характеристика лицензии, а не счётчик. Кажется мелочью, но именно на таких мелочах вы решаете, читать отчёт дальше или закрыть вкладку.

srvinfo на 119 ГБ и волшебный батник

Тут начинается самое вкусное. Папка srvinfo весит 119 ГБ, внутри больше двенадцати тысяч файлов. Классика жанра: нагуглить «батник для очистки кэша сервера 1С», запустить и порадоваться свободному месту. Агент вместо этого полез смотреть, что внутри, и первым же номером вытащил полнотекстовый индекс рабочей базы на 20 ГБ. Снести его «как кэш» — это не уборка, а очень интересное утро для тех, кто завтра будет искать документ.

Журналы регистрации отъели ещё 50 ГБ и лежат в 68 каталогах. Баз в кластере, напомню, 16. Журнал рабочей базы весит 25,5 ГБ, старой копии — 10,4. Лишние каталоги очень похожи на хвосты давно удалённых баз, и агент так и сформулировал: похоже, но не доказано. Не «срочно удалить», не «найден мусор», а «похоже». С таким коллегой я бы работал.

На сдачу: на C: свободно 13%, а в Windows\Temp живут 334 тысячи файлов. По объёму это гигабайт, плевать. По количеству — привет проводнику, который рискнёт эту папку открыть.

Бэкап-призрак

Эту находку я считаю главной. Агент поднял историю бэкапов SQL Server: 444 штуки за месяц, сервер бэкапится как не в себя. По тестовой базе — ноль. Запрос шёл с правами sysadmin, так что версию «агенту просто не показали» можно сразу выкинуть.

Дальше агент докопался, откуда база вообще взялась: её восстановили 17 сентября из полной копии рабочей от 16-го. Родословная есть, а копии того, что в базе сейчас, нет. Для тестовой базы, может, и нормально. Но «бэкап вроде есть, просто никто не проверял» — одна из самых частых фраз, которые я встречал на форумах. И вот она, живьём, на сервере с 444 бэкапами.

Тормоза, которых не было

«1С тормозит» — жалоба номер один, и я ждал, что агент тут развернётся. Не развернулся. Процессор 5–7%, очередь диска 0–2, свободно 208 ГБ памяти из 512, rphost скромно ест около 5 ГБ. План питания уже «Высокая производительность», так что любимый совет из интернета «переключите питание» здесь не сработает.

Пороги памяти кластера стоят в нуле, и тут многие хватаются за голову: выключено! Агент сверился с документацией 8.3.27: ноль означает 80% и 95% памяти сервера, около 409 и 486 ГБ, трогать не надо. Техжурнал уже был настроен под рабочую базу двумя файлами logcfg.xml, и агент не стал перезаписывать его своей «правильной» версией. В журналах Windows за неделю 234 ошибки и предупреждения, от 1С ни одной, и агент сам уточнил, что это журнал Windows, а не журнал регистрации.

За это я зауважал его больше, чем за srvinfo. Агент, который на любом сервере находит проблемы, не помощник, а генератор тревожности. Полезен тот, кто способен сказать: на этом снимке всё спокойно. В 23:19 диагностика закончилась, и финальным штрихом агент проверил, что паролей нет в журналах.

Как он косячил

Косяков было семь, и все агент поймал сам. Лишняя скобка в первой же команде — классика. COM-свойства в PowerShell три раза подряд вернули пустоту, и агент не обрадовался «успеху», а перешёл на явный вызов. Скрипт с кириллицей PowerShell 5 не съел без BOM. Пути в logcfg.xml прочитались кракозябрами, и агент перечитал их с правильной кодировкой. Кто связывал 1С с PowerShell, узнал каждый пункт.

Два эпизода мне прямо понравились. Обход srvinfo упёрся в таймаут, и агент не выдал недосчитанное за итог, а пересчитал заново. И пароль: безопасного способа передать его в моём инструменте нет, это мой косяк. Агент сам собрал временный зашифрованный канал, в конце снёс его и проверил журналы: ноль совпадений.

Расширение за шесть секунд

В 23:42 я дал «давай» на одно действие: создать пустое расширение в тестовой базе. Там уже жили восемь чужих расширений, так что поле для «случайно задел» было. Первая попытка упала: платформа потребовала синоним в формате НСтр(), хотя по документации параметр выглядит необязательным. Привет, 1С, мы тебя тоже любим. Со второй попытки расширение создалось, сама команда заняла 6,1 секунды.

А дальше агент сделал то, что я хотел бы видеть после каждого изменения в любой базе. Сравнил идентификатор поколения основной конфигурации и хеши всех восьми чужих расширений до и после. Всё совпало. Копию пустого расширения сложил в .cfe и XML.

Модуль с функцией ВерсияРасширения() агент написал, но только в файлах. Загружать и компилировать не стал: разрешение было на пустое расширение, и точка. В 23:55 подчистил временные данные доступа и сдал смену.

Где кончается доверие

Теперь неприятная, но обязательная часть. Local Commander не песочница: команды выполняются с правами учётки Windows, под которой он запущен. Доступ можно сузить до выбранных папок, запретить команды, отозвать компьютер в любой момент. Но «остальные базы только смотреть» в этом эксперименте держала модель, а не инструмент. Изменений в других базах не было. А провокацию вроде «заверши-ка сеансы в рабочей базе» я не задавал, так что как бы он себя повёл, честно не знаю.

И про данные. Команды и их результаты идут через сервис и чат с ИИ. Конфигурацию к себе выгружать не нужно, но рассказывать, что «данные не покидают сервер», я не буду, это неправда. Официально инструмент заявлен под Windows 11, на Server 2022 у меня завёлся.

Обещанный список того, что чинить:

• нет безопасного канала для паролей, агент выкручивался сам;

• непонятно, какие переменные окружения доходят до команд — даже COMPUTERNAME не было;

• файлы пишутся без BOM, и PowerShell 5 ломает кириллицу;

• «команда выполнилась» и «задача выполнена» пока одно и то же, а большой вывод обрезается.

Чего я не трогал

Эта часть почти целиком про «посмотреть». Не проверены завершение висящих сеансов, запрет и снятие запрета входа, обновление при живых пользователях с монопольным режимом. Не проверены загрузка и компиляция кода в расширение, техжурнал во время тяжёлой операции, очистка кэша кластера и перезапуск служб. Причину тормозов агент не искал по уважительной причине: тормозов не было. Всё, что реально что-то меняет, будет во второй части, и там будет страшнее.

Вопрос к вам

Не спрашиваю, нравится ли идея. Спрошу конкретнее: что из вашей серверной рутины вы отдали бы такому агенту хоть завтра? А что не отдали бы ни при каких правилах — и почему?

Если захотите погонять на своём тестовом сервере: ставится командой npx local-commander-agent@latest, нужен Node.js 20+, пакет на npm называется local-commander-agent. Особенно жду отчётов, где что-то пошло не так. Они полезнее.