Defuser в 1С: что это за фоновое задание

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

Короткий ответ: Defuser — это не штатный механизм платформы 1С:Предприятие. Чаще всего задание с таким или похожим именем появляется из расширения конфигурации, дополнительной обработки, внешней компоненты или сторонней подсистемы, внедрённой при доработке. Реже подобные записи связаны с внешними утилитами, которые взаимодействуют с базой через COM-соединение или веб-сервисы и создают сеансы, похожие на фоновые задания.

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

Что такое фоновые задания в 1С и где их искать

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

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

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

Откуда берётся задание Defuser: типичные источники

Поскольку Defuser не является объектом типовых конфигураций 1С (Бухгалтерия, ЗУП, Управление торговлей, ERP), его появление всегда связано с доработкой. Наиболее вероятные источники:

• Расширение конфигурации. Расширения могут добавлять собственные регламентные задания и подписки на события. Проверьте список подключённых расширений: «Администрирование → Печатные формы, отчеты и обработки → Расширения» либо через конфигуратор.
• Внешние обработки и дополнительные отчёты. Механизм «Дополнительные отчеты и обработки» БСП умеет выполнять обработки по расписанию — в консоли заданий такие запуски могут иметь произвольные наименования.
• Сторонние подсистемы и внедрённые модули. При интеграциях (обмен с сайтом, CRM, телефонией, маркировкой) подрядчики часто добавляют свои регламентные задания с нестандартными именами.
• Внешние утилиты. Программы, подключающиеся к базе через COM или HTTP, могут создавать сеансы фонового типа, которые в консоли выглядят как задания.

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

Как найти источник задания: пошаговая диагностика

Начните с журнала регистрации. Откройте его в режиме «1С:Предприятие» (Администрирование → Журнал регистрации) или через конфигуратор, установите отбор по событию «Фоновое задание» и по имени Defuser. В записях будут видны время запуска, результат (успех или ошибка), пользователь, от имени которого выполняется задание, и текст ошибки, если она есть.

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

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

1. 1
   Откройте журнал регистрации и отфильтруйте события фоновых заданий по имени Defuser
2. 2
   Зафиксируйте пользователя, периодичность запуска и тексты ошибок
3. 3
   Проверьте список расширений конфигурации и дополнительных обработок
4. 4
   Найдите объект задания в метаданных через конфигуратор
5. 5
   Определите, какие данные обрабатывает задание, по коду обработчика или по логам
6. 6
   Примите решение: оставить, перенастроить расписание или отключить

Опасен ли Defuser: как оценить риски

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

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

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

Как безопасно отключить или ограничить задание

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

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

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

// Отключение регламентного задания программно
Отбор = Новый Структура("ИмяМетода", "ИмяМетодаОбработчика");
Задания = РегламентныеЗадания.ПолучитьРегламентныеЗадания(Отбор);
Для Каждого Задание Из Задания Цикл
    Задание.Использование = Ложь;
    Задание.Записать();
КонецЦикла;

Проверка результата и профилактика

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

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

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

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

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

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