К статье
Практический материал

Администрирование · 13 мин

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

Что такое системное фоновое задание в 1С, чем отличается от обычного фонового задания, где смотреть список, как диагностировать зависшие и ошибочные задания.

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

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

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

Что такое фоновое задание в 1С и чем системное отличается от обычного

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

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

Важно понимать связь с регламентными заданиями. Регламентное задание — это объект метаданных с расписанием; когда наступает время выполнения, планировщик порождает фоновое задание, которое и выполняет код. Поэтому в списке фоновых заданий большинство системных записей — это экземпляры регламентных заданий, запущенные по расписанию.

Какие системные задания выполняются в типовой базе

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

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

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

Где посмотреть список системных фоновых заданий

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

Внутри прикладного решения удобнее использовать обработку «Консоль заданий» (в типовых конфигурациях — «Регламентные и фоновые задания», обычно в разделе администрирования). Она показывает список регламентных заданий с расписаниями и журнал выполнения фоновых заданий с фильтрами по состоянию и периоду. Для файловой базы это фактически единственный штатный способ наблюдения.

Как найти системное фоновое задание
  1. 1
    Откройте в типовой конфигурации раздел «Администрирование» → «Обслуживание» → «Регламентные операции» (или «Регламентные и фоновые задания»).
  2. 2
    Перейдите на вкладку «Фоновые задания» и установите фильтр по периоду и состоянию, например «Завершено аварийно».
  3. 3
    Откройте свойства интересующего задания: посмотрите имя метода, ключ, время выполнения и описание ошибки.
  4. 4
    Сопоставьте задание с регламентным: по наименованию найдите его в списке регламентных заданий и проверьте расписание и признак «Использование».
  5. 5
    При необходимости проверьте журнал регистрации по событию с именем метода задания за тот же период.

Для глубокой диагностики используется технологический журнал с событиями TLOCK, TDEADLOCK и событиями фоновых заданий, а также журнал регистрации с отбором по типу события «Фоновое задание». Эти инструменты требуют аккуратности: включение расширенного логирования увеличивает нагрузку на дисковую подсистему.

Типичные проблемы и как их диагностировать

Самая частая жалоба — «задание зависло». На практике это обычно один из трёх сценариев: задание действительно выполняется долго (большой объём данных), задание заблокировано ожиданием на СУБД, либо сеанс «повис» после аварийного завершения рабочего процесса. Отличить ситуации помогает консоль кластера: активный сеанс с растущим временем вызова СУБД — это работа или блокировка, а сеанс без активности — вероятный «мёртвый» остаток.

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

Контрольные точки

Как проверить состояние задания

Состояние в списке фоновых заданий
Норма

«Завершено» за разумное время, характерное для объёма данных

Тревожный признак

«Завершено аварийно» или «Выполняется» часами без изменений

Сеанс в консоли кластера
Норма

Сеанс активен, время вызова СУБД растёт — задание реально работает

Тревожный признак

Сеанс есть, но активности нет — вероятен зависший остаток

Текст ошибки в свойствах задания
Норма

Ошибки нет, задание отработало

Тревожный признак

Повторяющаяся одна и та же ошибка при каждом запуске

Журнал регистрации за период выполнения
Норма

События начала и успешного завершения

Тревожный признак

События ошибок с именем метода задания

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

Как безопасно вмешаться: отключение, перезапуск, отмена

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

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

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

Типичные ошибки администраторов
01
Отключение «лишних» регламентных заданий без анализа — приводит к остановке обменов, устареванию итогов и переполнению таблиц протоколов.
02
Запуск тяжёлых заданий в рабочее время по слишком частому расписанию — конкуренция за ресурсы СУБД и блокировки у пользователей.
03
Принудительное завершение сеансов без диагностики — обрыв транзакций и рассинхронизация данных в обменах.
04
Игнорирование повторяющихся аварийных завершений — ошибка накапливает отставание (неотправленные сообщения, необновлённый индекс).
05
Выполнение заданий от имени пользователя с избыточными правами вместо выделенной служебной учётной записи.

Оптимизация расписаний и нагрузки

Основной приём снижения нагрузки от системных заданий — грамотное расписание. Тяжёлые операции (пересчёты, полная синхронизация, очистка больших таблиц) переносятся на ночное окно с минимальной пользовательской активностью. Частые лёгкие задания (проверка очередей) могут выполняться днём, но с разумным интервалом: запуск каждую минуту нескольких заданий одновременно создаёт постоянный фон нагрузки на кластер и СУБД.

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

Маршрут решения

Как выбрать действие

Задание завершается аварийно с одной и той же ошибкойИсправьте причину (код, права, доступность ресурса), затем запустите задание вручную для проверки
Задание выполняется много часов, сеанс активен в консоли кластераПроверьте объём данных и блокировки; вероятно, нужна оптимизация кода или перенос в ночное окно
Сеанс задания есть, но активности нет длительное времяЗадание зависло — завершите сеанс и проверьте журнал регистрации на причину зависания
Задание мешает пользователям днёмИзмените расписание регламентного задания на нерабочее время, не отключая его полностью
Назначение задания неизвестноНе отключайте: найдите описание в документации конфигурации или уточните у разработчика

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

Частые вопросы о системных фоновых заданиях 1С

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

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

Можно ли удалить системное фоновое задание из списка?

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

Почему задание завершается с ошибкой «Пользователь не найден» или ошибкой прав?

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

Как запустить регламентное задание вручную, не дожидаясь расписания?

В типовых конфигурациях в консоли заданий есть команда «Выполнить сейчас» для выбранного регламентного задания. Задание запустится в фоне, результат будет виден в списке фоновых заданий. Для заданий обмена данными учитывайте, что ручной запуск создаст внеочередной сеанс синхронизации.

Опасно ли отключить системное задание, которое грузит сервер?

Зависит от задания. Отключение очистки протоколов или обновления поискового индекса относительно безболезненно на коротком горизонте, а отключение обменов или расчёта итогов нарушает учётные процессы. Правильная стратегия — не отключать, а переносить в нерабочее время и снижать частоту запуска, предварительно выяснив назначение задания.

Почему в файловой базе регламентные задания не выполняются?

В файловом варианте нет сервера 1С, поэтому задания исполняет отдельно запущенный клиентский сеанс, в котором разрешено выполнение регламентных заданий. Если такой сеанс не запущен, закрыт или база открыта в монопольном/заблокированном состоянии, задания просто не стартуют. Проверьте наличие сеанса-исполнителя и настройку ожидания запуска.

Итог

Что важно запомнить

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