ИИ-агент на сервере 1С:УХ: 15 минут диагностики, одно расширение и честный список ошибок
Утро. Бухгалтер пишет в чат: «1С опять глючит».
Админ открывает RDP, консоль кластера, диспетчер задач и начинает собирать картину по кусочкам. Я решил проверить, сколько этой рутины можно отдать ИИ-агенту из обычного чата — и где он сломается.
Что проверял и почему именно это
Сценарии я не придумывал, а взял из того, на что годами жалуются на Инфостарте, buh.ru и Хабр Q&A. Висящие сеансы, которые держат лицензии. «Не обнаружена лицензия». «Не удалось установить монопольный режим». Бэкап, который «вроде есть». У вопроса про тормоза 1С больше 11 тысяч просмотров, а единого ответа там так и нет.
Вопрос был простой. Если дать агенту доступ к серверу и объяснить задачу человеческими словами, что он сделает сам, без подсказок команд? Проверял на тестовой копии рабочей базы, по жёстким правилам.
Стенд
- 1С:Управление холдингом 3.2.6.85, платформа 8.3.27.
- MS SQL Server на том же сервере, файл данных базы около 70 ГБ.
- Сервер базы: Windows Server 2022, 64 логических ядра, 512 ГБ памяти. Кластер на 16 баз, рабочие процессы на двух серверах.
- Агент стоял не на сервере базы, а на соседней машине с Windows Server 2022 в той же сети. С неё он ходил к кластеру, к SQL Server и к Windows сервера.
- Связка: ИИ-клиент плюс Local Commander — инструмент, который выполняет команды ИИ на выбранном компьютере. Его делаю я, так что интерес у меня не академический.
Правила, которые получил агент:
- Менять можно только тестовую базу. Остальные базы кластера — только смотреть.
- Код — только в расширении. Основную конфигурацию не трогать.
- Перед любым изменением — план и моё «давай».
- Службы и кэш кластера не трогать без отдельного окна обслуживания.
Задание было одним сообщением: реквизиты, правила, список ситуаций и структура отчёта. Дальше агент работал сам.
Первый сюрприз: RAC не отвечает
Агент начал с инвентаризации и попробовал rac на порт 1545. Сервер администрирования оказался недоступен. Вместо просьбы запустить ras агент подключился к агенту кластера штатным COM-интерфейсом по порту 1540. Так он прочитал кластер: 16 баз, рабочие процессы, сеансы, настройки памяти. На сервере для этого ничего не устанавливалось и не запускалось.
Что он нашёл за 15 минут
Диагностика заняла 15 минут по часам, от первой команды до отчёта. Ниже — находки, которые мне как админу показались полезными.
srvinfo — 119 ГБ, и это не мусор. Из них 50 ГБ — журналы регистрации в 68 каталогах, хотя баз в кластере 16. Журнал рабочей базы занимает 25,5 ГБ, журнал старой копии — 10,4 ГБ. Самый крупный файл в srvinfo — полнотекстовый индекс рабочей базы, 20,5 ГБ. Совет «почистите srvinfo» здесь был бы ошибкой, и агент написал это прямо.
На диске C: свободно 13%. Это 78 ГБ из 600. Пока терпимо, но при журналах на 50 ГБ это вопрос времени.
В Windows\Temp 334 тысячи файлов на 1 ГБ. По объёму не страшно, по количеству — да: такую папку долго обходит и антивирус, и бэкап.
Бэкапа тестовой базы нет. В истории бэкапов SQL Server 444 записи за месяц, и ни одной по тестовой базе. Агент нашёл, откуда она взялась: её восстановили из полной копии рабочей базы 17 сентября. Происхождение известно, а копии текущего состояния нет — классический «бэкап вроде есть». Запрос шёл с правами sysadmin, так что дело не в нехватке прав.
Тормозов на снимке нет, и он не стал их выдумывать. Процессор 5–7%, свободно 208 ГБ памяти, план питания «Высокая производительность», у rphost около 5 ГБ. Из 234 предупреждений и ошибок в журналах Windows за неделю ни одной от 1С. Вывод агента: для расследования «тормозит» нужен повторяемый сценарий и замеры во время него.
Нули в настройках памяти — не «выключено». Пороги памяти кластера стояли в 0. Агент сверился с документацией 8.3.27: 0 означает 80% и 95% памяти сервера, то есть около 409 и 486 ГБ. До этих значений далеко. Менять ничего не нужно, тем более что на этом же сервере работает SQL Server.
Лицензии: без домыслов. У одного сеанса была клиентская лицензия на 10 пользователей. Агент отдельно отметил: 10 — это характеристика лицензии, а не «занято 10». Полную занятость по одному снимку он устанавливать не стал.
Техжурнал уже настроен. Нашлись два logcfg.xml, каталоги на отдельном диске и фильтры под рабочую базу. Пустая папка logs в srvinfo не означала, что техжурнала нет. Агент не стал перезаписывать настройку и предложил для теста отдельный фильтр под тестовую базу с возвратом прежних настроек.
Разработка: расширение, не выходя с сервера
Дальше — то, ради чего многие собирают связки «Cursor + MCP + выгрузка»: изменить код. Расширения LC_Test в базе не было. Агент сказал об этом и остановился. После моего «давай» он создал расширение пакетным режимом конфигуратора, через агент конфигуратора.
Первая попытка упала за две миллисекунды: платформа потребовала synonym в формате НСтр(), хотя в документации параметр выглядит необязательным. Вторая прошла за 6,1 секунды. Агент сохранил копию пустого расширения (.cfe, 4880 байт) и XML-выгрузку. Потом проверил то, что я проверил бы и сам: идентификатор поколения основной конфигурации и хеши восьми уже существующих расширений до и после совпали.
Модуль с функцией ВерсияРасширения() агент подготовил в файлах выгрузки, но загружать не стал. Это отдельное изменение, а «давай» было только на пустое расширение. Компиляция и загрузка модуля — во второй части.
Где он спотыкался
Это самая полезная часть отчёта, поэтому без сокращений.
|
Что случилось |
Как выкрутился |
|---|---|
|
Лишняя скобка в команде инвентаризации |
Увидел ошибку разбора, исправил, повторил |
|
COM-свойства в PowerShell возвращали пусто |
Перешёл на InvokeMember и правильный разбор COM-массива; ложный «успех» по пустому значению отловил сам |
|
Скрипт с кириллицей не разобрался в PowerShell 5 |
Файл был в UTF-8 без BOM; добавил BOM |
|
Обход srvinfo упёрся в ограничение по времени |
Не выдал частичный размер за полный, сделал отдельный полный обход |
|
Кириллица в путях logcfg.xml прочиталась криво |
Перечитал XML с учётом его кодировки |
|
Пароль некуда безопасно передать |
Сделал временный зашифрованный канал; после работы удалил его и проверил, что пароль не попал в журналы |
|
Слишком большой вывод обрезался |
Пересобрал компактный результат |
Кириллица, PowerShell 5 и COM — ровно те грабли, на которые наступает каждый, кто автоматизирует 1С на Windows. Разница в том, что агент наступал на них за секунды и сам же их обходил. И важнее всего: он не выдавал неполный результат за полный.
Про безопасность — до того, как спросят
С соседней машины агент прочитал журналы Windows, диски и историю бэкапов SQL Server сервера базы. Никакой магии: ему дали учётные записи с такими правами. Инструмент выполняет команды с правами той учётной записи, под которой работает. Это не песочница.
Правило «другие базы только смотреть» держал ИИ, а не инструмент: Local Commander не знает, какая база тестовая, а какая рабочая. В этом прогоне ни одного изменяющего действия с другими базами не было. Но если пускаете агента на сервер с рабочими базами, давайте ему отдельную учётную запись с минимальными правами, а не свою.
И не пишите пароли в чат. Всё, что вы туда вставили, остаётся в истории переписки.
Что ещё не проверено
В этой части нет висящих сеансов, монопольного режима при обновлении, запрета входа, эксперимента с техжурналом и очистки кэша кластера. Для них нужно подготовить состояние — открыть сеансы, включить запрет — и найти окно обслуживания: кластер общий с рабочими базами. Это вторая часть.
Итог
За 15 минут агент собрал картину, на которую руками у меня ушло бы [оценка — поправь, например «час-полтора»]: кластер, диски, журналы, память, лицензии, бэкапы. Он не придумывал проблем там, где их нет, и останавливался перед каждым изменением. Ошибался, но в мелочах, и сам себя поправлял.
А теперь вопрос к вам. Какую рутину на сервере 1С вы бы отдали такому агенту, а какую — никогда?
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
