1С: как определить фоновое задание и найти источник проблемы

Фоновое задание в 1С — это сеанс, который выполняет код без участия пользователя: обмен данными, расчёт итогов, загрузка курсов валют, отправка отчётов. Когда база «тормозит», документы не проводятся или обмен не проходит, первым шагом диагностики становится определение, какое именно фоновое задание выполняется в данный момент и не зависло ли оно.

Определить фоновое задание можно несколькими способами: через стандартную обработку «Консоль заданий», через журнал регистрации, программно — методами менеджера фоновых заданий, а в клиент-серверном варианте — через консоль кластера серверов 1С. Выбор способа зависит от того, что нужно узнать: сам факт выполнения, имя процедуры, пользователя-инициатора или причину зависания.

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

Что такое фоновое задание и чем оно отличается от регламентного

Фоновое задание — это механизм платформы, который запускает выполнение процедуры общего модуля в отдельном сеансе, не блокируя работу пользователя. Программист создаёт его методом ФоновыеЗадания.Выполнить(), указывая имя метода, параметры и ключ. Задание получает уникальный идентификатор (UUID), по которому его можно найти и идентифицировать.

Регламентное задание — это расписание, настроенное в конфигураторе: платформа сама периодически порождает фоновые задания по этому расписанию. То есть каждое выполнение регламентного задания — это отдельное фоновое задание со своим сеансом и идентификатором. Когда администратор ищет «что сейчас грузит сервер», он ищет именно фоновое задание, а уже потом выясняет, каким регламентным заданием или каким пользователем оно порождено.

Как определить активное фоновое задание через консоль заданий

В типовых конфигурациях на БСП (УТ, ERP, Бухгалтерия, ЗУП) встроена обработка «Консоль заданий»: раздел «Администрирование» → «Обслуживание» → «Регламентные и фоновые задания», либо «Регламентные операции» в зависимости от версии. Откройте её и перейдите на закладку «Фоновые задания» — таблица покажет все задания с фильтрами по состоянию и периоду.

Установите отбор по состоянию «Активно» — вы увидите, что выполняется прямо сейчас: наименование задания, имя метода, момент начала, ключ и связанное регламентное задание. Если задание «висит» в активном состоянии заметно дольше своего обычного времени выполнения — это первый признак зависания.

Двойной щелчок по строке открывает подробности, включая информацию об ошибке для заданий в состоянии «Ошибка». Текст ошибки — ключ к определению причины: конфликт блокировок, недоступность внешнего ресурса, ошибка в коде метода.

1. 1
   Откройте «Администрирование» → «Обслуживание» → «Регламентные и фоновые задания»
2. 2
   Перейдите на закладку «Фоновые задания»
3. 3
   Установите отбор по состоянию «Активно» или «Ошибка»
4. 4
   Найдите задание по имени метода, ключу или времени начала
5. 5
   Откройте карточку задания и изучите сообщение об ошибке, если оно есть
6. 6
   Сверьте длительность выполнения с обычной для этого задания

Как найти фоновое задание программно

Когда консоль недоступна (нет прав, нетиповая конфигурация) или нужна автоматическая проверка, используют метод ФоновыеЗадания.ПолучитьФоновыеЗадания(). Он принимает структуру отбора: состояние, имя метода, ключ, уникальный идентификатор, регламентное задание.

Отбор = Новый Структура("Состояние", СостояниеФоновогоЗадания.Активно);
АктивныеЗадания = ФоновыеЗадания.ПолучитьФоновыеЗадания(Отбор);
Для Каждого Задание Из АктивныеЗадания Цикл
    Сообщить(Задание.Наименование + " | " + Задание.ИмяМетода
        + " | начато: " + Задание.Начало
        + " | УИД: " + Задание.УникальныйИдентификатор);
КонецЦикла;

По уникальному идентификатору задание находится методом ФоновыеЗадания.НайтиПоУникальномуИдентификатору(УИД). Это стандартный приём, когда процедура запускает задание и сохраняет UUID, чтобы позже проверить его состояние или получить результат из временного хранилища.

Учтите ограничение: получить список заданий может только код, выполняющийся с правами администрирования, либо задание видит только «само себя». В файловой базе без сервера 1С фоновые задания выполняются в отдельном клиентском процессе, и их видимость через менеджер сохраняется, но сеанс в консоли кластера вы не увидите — его там просто нет.

Как определить фоновое задание через журнал регистрации

Журнал регистрации — главный источник, когда задание уже завершилось или упало с ошибкой, и консоль заданий ничего не показывает. Откройте «Администрирование» → «Обслуживание» → «Журнал регистрации» и настройте отбор.

Полезные фильтры: события с важностью «Ошибка», поиск по имени метода задания в поле «Данные» или «Комментарий», отбор по пользователю, от имени которого стартовал сеанс. Фоновые сеансы в журнале отображаются с именем пользователя, под которым было запущено задание, и видом сеанса «Фоновое задание».

Для регламентных заданий платформа пишет события запуска и завершения с указанием имени задания. Если в журнале виден старт регламентного задания, но нет события завершения, а в консоли заданий оно активно уже долго — вы определили зависшее задание. Дальше остаётся найти его сеанс и принять решение об отмене.

Как связать фоновое задание с сеансом в консоли кластера

В клиент-серверном варианте каждое активное фоновое задание — это сеанс на сервере 1С. Откройте консоль администрирования серверов, раскройте кластер → нужную информационную базу → «Сеансы». Сеансы фоновых заданий имеют вид приложения «Фоновое задание» и обычно небольшое время простоя, если реально работают.

Признаки зависшего сеанса: нулевая или застывшая активность (колонки «Прочитано», «Записано», «Время вызова СУБД» не меняются при обновлении), длительное время работы, отсутствие текущего вызова. Сопоставить сеанс с конкретным заданием помогают имя пользователя, время начала сеанса и номер соединения, который фигурирует в журнале регистрации и в технологическом журнале.

Если нужно точно определить, какой SQL-запрос выполняет зависшее задание, включите технологический журнал с событиями DBMSSQL/DBPOSTGRS и отфильтруйте по номеру соединения. Это уже работа для опытного администратора: ошибка в настройке ТЖ может резко увеличить нагрузку на диск.

Как определить, кто и что запустило задание

В карточке фонового задания в консоли заданий видно поле «Регламентное задание»: если оно заполнено — источником является расписание из конфигурации. Если поле пустое, задание запущено программно: пользователем из интерфейса (например, «Загрузить курсы валют»), другим фоновым заданием или внешним вызовом через веб-сервис.

Имя метода (ИмяМетода) указывает на процедуру общего модуля — по нему в конфигураторе через глобальный поиск находится код, который выполняет задание. Ключ задания — произвольная строка, которую разработчик использует для группировки: по ней часто можно понять прикладной смысл, например «ОбменССайтом_Заказы».

Пользователь сеанса показывает, от чьего имени выполняется код. Для регламентных заданий это пользователь, указанный в настройке задания (или пользователь с пустым именем — тогда задание выполняется от имени служебного сеанса). Если права этого пользователя изменили, задание может начать падать с ошибками доступа — это частая причина «внезапно сломавшихся» обменов.

Типичные ошибки при поиске и диагностике заданий

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

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

Третья ошибка — многократный ручной перезапуск задания, которое уже выполняется. Платформа не всегда блокирует дубли, и два параллельных обмена могут создать конфликты блокировок и дубли данных. Перед повторным запуском всегда проверяйте список активных заданий по имени метода или ключу.

Как проверить результат после диагностики

После отмены или перезапуска задания убедитесь, что ситуация нормализовалась: в консоли заданий нет зависших активных заданий, новое выполнение завершается в разумное время, в журнале регистрации появляется событие успешного завершения без ошибок.

Для обменов данными дополнительно проверьте прикладной результат: документы дошли до базы-приёмника, очередь сообщений обмена пуста, нет предупреждений в протоколе обмена. Сам факт завершения задания без ошибки не гарантирует, что данные перенеслись корректно, — сообщение могло быть принято с предупреждениями.

Частые вопросы