Отчёт по серверу 1С без догадок: что собрать до того, как искать виноватого

Бухгалтеры пишут «1С тормозит». Утром кто-то увидел «не обнаружена лицензия». Диск на сервере заканчивается, а кто его забил — непонятно. В каждом таком случае первый вопрос один и тот же: а что на самом деле происходит на сервере прямо сейчас? Не «что мы думаем», а что видно.

Я двадцать с лишним лет работаю на стороне ИТ, последние годы в основном с учётными системами и интеграциями. Мне много раз приходилось разбирать чужие проблемы с 1С, не имея под рукой ни полной картины, ни времени. Самая частая ошибка в таких разборах не техническая. Люди начинают с версии («это, наверное, rphost»), а не с фактов, и дальше спорят о версии. Ниже — порядок, который я использую, чтобы собрать технический отчёт по серверу 1С до того, как кто-то скажет «виноват сервер» или «виноват код». Все цифры в тексте из двух реальных прогонов на кластере 1С под Windows Server 2019 (платформа 8.3.27, 16 баз в кластере), 17 и 23 октября 2026 года. Агент стоял на соседней машине под Windows Server и ходил к кластеру по сети. Имена серверов и баз я убрал.

Зачем вообще отчёт, если можно «просто посмотреть»

Потому что «просто посмотреть» каждый делает по-своему, и через час у вас три разные версии. Отчёт нужен, чтобы:

• отделить наблюдения от предположений;
• зафиксировать период, за который смотрели журналы, а не «где-то на прошлой неделе»;
• передать разбор дальше (франчайзи, программисту, хостеру) без пересказа по телефону;
• через месяц сравнить «как было» и «как стало».

Он не обязан быть длинным. Хороший отчёт на одну страницу лучше, чем сорок скриншотов.

Шесть блоков отчёта

1. Площадка: ОС, платформа, службы

Сначала то, что не меняется от минуты к минуте: версия Windows, версии платформы в C:\Program Files\1cv8, службы 1С и под какой учётной записью они запущены, порты, которые слушает кластер. Это тот блок, который обычно никто не записывает, а потом выясняется, что версия клиента и сервера разошлись после обновления — и «ошибка формата потока» объясняется за минуту.

Фрагмент скрипта, который я использую для инвентаризации (Windows PowerShell 5.1, только чтение):

$base = Join-Path $env:ProgramFiles '1cv8'
$platformVersions = @(Get-ChildItem $base -Directory |
    Where-Object { $_.Name -match '^\d+\.\d+\.\d+\.\d+$' } |
    Select-Object -ExpandProperty Name)

$services = @(Get-CimInstance Win32_Service |
    Where-Object { $_.Name -like '*1C*' -or $_.DisplayName -like '*1C*' -or $_.Name -eq 'hasplms' } |
    Select-Object Name, State, StartMode, StartName, PathName)

$ports = @(1540, 1541, 1545) + (1560..1591)
$listening = @(Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
    Where-Object { $ports -contains $_.LocalPort } | Sort-Object LocalPort -Unique)

В отчёт идут не сами команды, а их результат: «Windows Server 2019, платформа 8.3.27.x, служба агента запущена под такой-то учёткой, порты 1540/1541 слушаются, 1545 закрыт». Последняя деталь, кстати, всплыла в первом прогоне: порт RAS 1545 на сервере был закрыт, и отчёт по кластеру пришлось собирать через COM-подключение на 1540. Если бы это не было записано, следующий человек потратил бы на тот же тупик свои полчаса.

2. Процессы и память

Для каждого rphost — PID, занятая память, время старта. Рядом — настройки кластера: пороги памяти рабочих процессов и интервал перезапуска. В прогоне 17 октября пороги стояли в нуле; агент сверил это с документацией 8.3.27 (по умолчанию платформа использует 80 % и 95 % оперативной памяти) и написал, что менять ничего не нужно. Это правильный вывод и правильная форма: «пороги 0, означает значения по умолчанию, источник — документация», а не «надо выставить лимит».

Get-Process -Name ragent, rmngr, rphost, ras -ErrorAction SilentlyContinue |
    Select-Object ProcessName, Id,
        @{ n = 'MemoryMb'; e = { [math]::Round($_.WorkingSet64 / 1MB) } },
        @{ n = 'Started'; e = { try { $_.StartTime.ToString('s') } catch { $null } } }

3. Нагрузка на момент снимка

Процессор, свободная память, очередь диска, схема электропитания. Важно: это снимок, и в отчёте так и должно быть написано. В прогоне по жалобе «страшно тормозит» сервер в момент проверки был свободен: процессор 5–7 %, 208 ГБ свободного места. Агент не стал придумывать причину и попросил повторяемый сценарий: какая операция, у кого, во сколько. Это единственно честный ответ, когда снимок ничего не показывает. «Сейчас всё в порядке» не опровергает жалобу, оно только означает, что проблему нужно ловить в момент её появления, а не после.

4. Диск: что именно занимает место

Здесь нужны размеры по каждой базе отдельно, а не «папка srvinfo большая». В прогоне 17 октября получилось так: srvinfo — 119 ГБ; журналы регистрации — 50 ГБ в 68 каталогах при 16 базах; самый большой отдельный файл — полнотекстовый индекс на 20 ГБ. Первый обход дал неполную цифру, и обход пришлось повторить, уже с правильным учётом вложенных каталогов. В отчёте оба факта: итоговые размеры и то, что первый подсчёт был неверным. Второе важнее, чем кажется: тот, кто будет чистить диск, должен знать, что цифры проверены дважды.

Что в этом блоке не делается: ничего не удаляется. Отчёт отвечает на вопрос «что занимает место», а не «что можно снести».

5. Резервные копии: не «есть ли», а «какие и для кого»

Самый неприятный результат в прогонах был здесь. На сервере нашлось 444 файла резервных копий, и ни одного по тестовой базе: она была восстановлена из копии рабочей месяц назад, и с тех пор копий не делалось. Если бы вопрос звучал «есть ли бэкапы», ответ был бы «да, 444». Правильный вопрос — «когда последняя копия этой базы, где лежит, какого размера». На него ответ «нет». Для рабочих баз такой разрыв между «бэкапы делаются» и «бэкап этой базы есть» встречается постоянно.

6. Журналы за выбранный период и открытые вопросы

Период нужно назвать явно. «Ошибки 1С за последние 7 дней из журнала Windows, уровни критический/ошибка/предупреждение, источники с «1C» в названии, не более 30 записей» — это проверяемая область. «Посмотрел логи, ничего страшного» — нет.

$since = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; Level = 1, 2, 3; StartTime = $since } -ErrorAction SilentlyContinue |
    Where-Object { $_.ProviderName -like '*1C*' } |
    Select-Object -First 30 TimeCreated, LevelDisplayName, ProviderName, Message

Последний раздел отчёта — вопросы, на которые данных не хватило. В моих прогонах это выглядело так:

• По лицензиям: видна одна клиентская лицензия, параметр MaxUsers=10 у базы — это ограничение, а не «занято 10». Полная занятость лицензионных пулов не установлена; нужен отчёт rac session list --licenses в момент ошибки.
• По «тормозит»: нагрузки в момент снимка нет; нужен повторяемый сценарий и техжурнал на время операции.
• По техжурналу: на сервере уже есть настроенный logcfg.xml под рабочую базу. Его не трогали; включать свой техжурнал поверх чужого без согласования нельзя.

Открытый вопрос в отчёте — не признак слабого разбора. Это признак, что разбор не подменяет факты догадками.

Что агент сделал не так, и почему это тоже идёт в отчёт

Я собирал эти отчёты не руками, а через ИИ-агента, которому дал доступ к серверу (о том, как именно, ниже). Для методики это неважно: те же шесть блоков собираются вручную или скриптами. Но ошибки агента оказались поучительными, и я записывал их отдельной колонкой:

• Обход диска в первый раз был неполным; цифры пересчитаны.
• Один клиентский лицензионный файл был виден, а занятость пулов — нет; агент так и написал, не округлив до «лицензий хватает».
• При создании расширения в тестовой базе платформа отвергла строку ObjectBelonging=Own в описании нового модуля (у собственных объектов расширения её нет); загрузка прошла со второй попытки, но ответ конфигуратора из нескольких JSON-массивов подряд скрипт разобрал только с третьей. Команда config check-modules в пакетном режиме не распозналась. Всего 3 попытки, загрузка 1,7 с, применение 2,3 с.
• В тестовой базе всё это время работал живой человек: 4 сеанса тонкого клиента. Агент нашёл его до каких-либо изменений и сообщил. Пока пользователь работал, завершать его сеансы агент отказывался; изменение модуля расширения применилось при 5 открытых сеансах без монопольного режима, потому что менялся только модуль.
• Висящий сеанс упавшего клиента (убитый процесс 1cv8c) держал лицензию больше минуты, в первой попытке больше четырёх; агент завершил только его.

Колонка «где ошибся и как выкрутился» нужна не для самобичевания. Она говорит читателю отчёта, какие цифры проверены повторно, а какие получены с первого раза.

Шаблон

Если собрать всё вместе, отчёт выглядит так:

Как это собиралось у меня

Я делаю Local Commander, так что здесь я не беспристрастен. Это маленький агент на сервере, который даёт чату с ИИ (в первом прогоне обычный чат, во втором Claude Code) читать файлы, запускать команды и смотреть результат. В описанных прогонах я задавал рамки первым сообщением: тестовая база — можно всё, остальные базы только смотреть, перед любым изменением — спросить. Рамки держал сам ИИ, а не продукт: Local Commander не знает, где рабочая база, а где тестовая, и это не песочница. Одобренный сервер даёт ИИ ровно те права, что есть у учётной записи агента. Поэтому первый шаг у меня был только чтение, и к изменениям в тестовой базе я перешёл после того, как отчёты по чтению сошлись с моими контрольными скриптами.

Нужен ли для такого отчёта агент — нет. Нужен порядок: площадка, процессы, нагрузка, диск, копии, журналы за названный период, вопросы. Чем бы вы его ни собирали, спорить потом будете о фактах, а не о версиях.

Если интересно, как я ограничиваю ИИ на серверах: https://localcmd.app/use-cases/guardrails-for-ai-on-your-servers