ИИ-агент диагностировал кластер 1С: обнаружены гигабайты мусора, но тормозов не найдено
Эксперимент по использованию ИИ-агента для анализа рабочего кластера 1С показал смешанные результаты. Автономная модель за 15 минут диагностики выявила критические проблемы хранения данных и неэффективность работы с бэкапами, однако не смогла найти причинных факторов для жалоб на «тормоза», так как они в данный момент отсутствуют. Автор эксперимента, использующий инструмент Local Commander, детально разбирает найденные аномалии и технические ограничения автоматизации в среде корпоративного ПО.
# ИИ-агент провёл аудит кластера 1С: 119 ГБ кэша и призрачные бэкапы, но «тормозов» нет
Ручное администрирование кластеров 1С, особенно в условиях высоких нагрузок, часто сопровождается типичными проблемами: висящие сеансы, неэффективное использование лицензий и раздутые объёмы хранения. На фоне этих хронических болей администраторов возникла идея делегировать часть диагностических задач искусственному интеллекту. В рамках эксперимента на реальном стенде ИИ-агент получил доступ к системе без прямого подключения к серверу (без RDP) и за короткое время составил подробный отчёт.
Ниже представлен протокол диагностики, выполненной ИИ-моделью на рабочем кластере 1С:Управление холдингом.
Стенд и границы доступа
Эксперимент проводился на субботах вечерами, когда нагрузка снижена. В качестве объекта диагностики выступал тестовый клон рабочей базы 1С:Управление холдингом 3.2.6.85, работающий на платформе 8.3.27.
Характеристики кластера: * База данных: MS SQL Server, файл данных около 70 ГБ. * Сервер: Windows Server 2022, 64 логических ядра, 512 ГБ оперативной памяти. * Архитектура: Кластер из 16 баз, распределённых по двум серверам обработки. * Схема подключения: Агент работал с соседней машины Windows Server 2022, используя сетевое соединение. Прямое подключение (RDP) к серверу базы не использовалось.
Правила безопасности (Prompt): Чтобы минимизировать риски, автор сформулировал пять строгих правил для ИИ-модели: 1. Изменения применяются только в тестовой базе; остальные базы доступны только для чтения. 2. Работа с основной конфигурацией запрещена. Код можно добавлять только в расширения. 3. Все действия по управлению службами и кэшем проводятся через окно обслуживания. 4. Пароли нельзя хранить в логах или открытом виде. 5. Любое изменение требует предварительного плана и подтверждения от человека.
Важно отметить, что соблюдение этих правил было результатом работы самой ИИ-модели, а не ограничения программного инструмента Local Commander, через который передавались команды.
Что выявил ИИ-агент
Диагностика длилась всего 15 минут. Первые трудности возникли сразу: порт RAC (1545) был закрыт, но агент успешно обошёл это, используя COM-интерфейс (порт 1540). Это позволило ему получить доступ к информации о сеансах, лицензиях и расширениях.
Проблема с лицензированием Одна из первых проверок касалась статуса лицензий. Система показывала наличие четырёх сеансов. Один из них был связан с клиентской лицензией на 10 пользователей. ИИ-модель корректно интерпретировала ситуацию: она поняла, что цифра «10» — это характеристика лицензии (количество одновременных рабочих мест), а не счётчик текущих подключенных пользователей. Это важный нюанс, так как новички часто воспринимают такие цифры как признак перегрузки системы.
Критический объём srvinfo
В папке srvinfo накопилось惊人的 количество данных: общий объём составил 119 ГБ, при этом внутри располагалось более 12 000 файлов. Анализ показал, что основную часть занимают не кэш, а полнотекстовый индекс рабочей базы (около 20,5 ГБ) и журналы регистрации (около 50 ГБ, разбросанные по 68 каталогам).
Агент сформулировал предположение, но не стал принимать его как истину: похоже, что в каталогах остались «хвосты» от давно удалённых баз, однако доказать это без проверки метаданных сложно. Неправильное удаление таких файлов (например, путём очистки кэша) может привести к потере данных о документах, которые должны были быть сохранены в полнотекстовом поиске.
Также было обнаружено, что в папке Windows\Temp находится более 334 тысяч файлов. Хотя их совокупный объём составляет менее 1 ГБ, их количество создаёт потенциальные проблемы для проводника и может указывать на ошибки в работе приложений.
Бэкап-призрак Одной из главных находок стало состояние системы резервного копирования. SQL Server выполнил 444 бэкапа за месяц (с 13 сентября по 17 октября), причём процесс шёл в автоматическом режиме. В то же время для самой тестируемой базы бэкапов не было создано вовсе.
Дальнейший анализ показал интересную цепочку событий: текущая тестовая база была восстановлена 17 сентября из полной копии рабочей базы от 16 сентября. Таким образом, «родословная» данных есть, но текущей копии для самостоятельного восстановления нет. Это классическая ситуация, когда администраторы полагаются на наличие бэкапов, но не проверяют их работоспособность или актуальность.
Миф о «тормозах»
Частой жалобой администраторов 1С является отсутствие производительности. Автор эксперимента ожидал, что ИИ-агент найдёт какие-то причины этого. Однако результаты показали обратное: «тормозов» в данный момент не обнаружено.
Мониторинг ресурсов: * Процессор: Использование составило 5–7%. * Очередь диска: 0–2%. Нет признаков деградации производительности дискового ввода-вывода. * Оперативная память: Свободно 208 ГБ из 512 ГБ. Процесс обработки запросов rphost потребляет около 5 ГБ. * Питание: План электропитания установлен на «Высокая производительность». Рекомендации по смене плана питания для этой системы неактуальны. * Пороги памяти: В кластере установлены порог срабатывания на 0%, что в документации платформы 8.3.27 означает 80% (около 409 ГБ) и 95% (около 486 ГБ). Поскольку свободной памяти гораздо больше, тревоги не должны срабатывать. * Технический журнал: Настроен и содержит два файла конфигурации logcfg.xml с фильтрами, ориентированными на рабочую базу. * События Windows: За неделю зафиксировано 234 ошибки и предупреждения операционной системы, но ошибок от платформы 1С не обнаружено.
Агент подтвердил, что система работает в штатном режиме. Это стало важным выводом: ИИ способен объективно оценить нагрузку и не генерировать ложные тревоги, когда проблем не существует.
Ошибки агента и их исправление
В процессе взаимодействия модель совершила несколько ошибок, но большинство из них смогла исправить самостоятельно. Это демонстрирует эволюцию поведения агента при работе со специфическими окружениями.
1. Синтаксические ошибки PowerShell: Первая команда содержала лишнюю скобку. Агент заметил ошибку, попробовал исправить её, но получил пустой ответ от свойства COM. В третьих попытке он перешёл на явный вызов команды, что разрешило задачу. 2. Проблема кодировки: При работе с путями к файлам конфигурации журнала (logcfg.xml) в PowerShell версии 5 возникли проблемы с кириллицей. Файлы прочитались неверно. Агент исправил ситуацию, добавив BOM (знак конца файла в кодировке UTF-8) в скрипт. 3. Обработка таймаутов: При переборе файлов в папке srvinfo агент столкнулся с таймаутом. Он не решил просто взять среднее значение, а пересчитал размер папки заново, потратив на это около 13,5 секунд. 4. Передача паролей: Поскольку в инструменте Local Commander отсутствует безопасный канал для передачи паролей, агент самостоятельно создал временный зашифрованный канал для доступа, выполнил задачу и сразу уничтожил канал. В логах пароли не были найдены. 5. Обрезка вывода: Некоторые длинные ответы обрывались. Агент пересобрал запрос так, чтобы получить компактный результат.
Технические ограничения и выводы
Эксперимент продемонстрировал потенциал ИИ в рутинной диагностике, но также выявил ряд ограничений текущего инструмента и моделей.
Ошибки на стороне инструмента (Local Commander): * Отсутствие безопасного механизма передачи паролей заставляет ИИ искать обходные пути, что снижает контролируемость процесса. * Неясность поведения переменных окружения: агент столкнулся с отсутствием переменной COMPUTERNAME, что может влиять на логику работы скриптов. * Проблемы с кодировкой файлов: скрипты без BOM не корректно обрабатывают кириллицу в старых версиях PowerShell (5.x). * Отсутствие различия между статусом «команда выполнена» и «задача решена» в больших объёмах данных приводит к обрезке вывода.
Что не было проверено: Автор не проверял завершение висящих сеансов, возможность обновления конфигурации без простоя, очистку кэша кластера или перезапуск служб с помощью ИИ. Поиск причин тормозов также не проводился, так как они объективно отсутствовали. Эти функции планируются для второй части эксперимента.
Резюме: ИИ-агент успешно идентифицировал скрытые проблемы с дисковым пространством (мусор в srvinfo, отсутствие бэкапов) и подтвердил стабильность работы сервера в отсутствие перегрузок. Способность модели самостоятельно корректировать ошибки синтаксиса, кодировки и безопасности (создание шифрованных каналов) является позитивным сигналом. Однако критические решения, такие как завершение сеансов или удаление данных, требуют постоянного человеческого контроля, так как инструмент действует с правами Windows-учётной записи и не имеет изоляции типа песочницы.
Вопрос к специалистам: какие именно рутинные задачи серверного администрирования 1С вы готовы делегировать ИИ-агентам прямо сейчас?