Задание включено. Расписание стоит правильное. В журнале ошибок по нему нет ни одной. И запусков тоже нет ни одного - за шестнадцать месяцев.
Разбор занял четыре дня, и первая версия причины была правдоподобной и неверной. Отклонить её удалось только замером. Настоящая причина сидела в поле карточки задания, которое смотрят реже всего.
Дальше по порядку: почему такой отказ не видно вообще ничем, какие четыре объяснения пришлось проверить и закрыть, чем всё оказалось и что из этого переносится на любую базу.
Отказ, у которого нет ни одного признака
Начну с того, что делает эту историю неприятной. У неё нет симптома.
Задание, которое падает, оставляет строку в журнале регистрации. Задание, которое тормозит, видно по длительности. Задание, которое отработало впустую, оставляет хотя бы отметку о запуске - с нулевым результатом, но оставляет.
Наше не оставляло ничего. В списке заданий оно выглядело безупречно: использование включено, расписание заполнено, ошибок нет. Ошибок нет ровно потому, что ошибке негде было возникнуть: код не выполнялся.
Тишина без ошибок - это не признак здоровья, это отсутствие данных. Пустой журнал по заданию читается как "всё хорошо", а означает "мы ничего не знаем". Разница между этими двумя прочтениями и есть цена вопроса.
Никто не замечал шестнадцать месяцев по простой причине: данные всё это время доезжали. Их довозили руками. Каждый, кто довозил, считал, что закрывает разовый сбой, и не спрашивал, почему сбой разовый уже который месяц.
Что показала история запусков
Первое, что мы сделали, когда вопрос наконец задали прямо, - подняли всю историю по этому заданию. Не последний запуск, а всю.
580 записей, и все до одной от ручных прогонов. Одного дня. Автоматических запусков нет вообще - ни за один день с апреля 2025 года, с момента, когда механизм завели.
Это то самое место, где перестаёшь искать причину неправильной работы и начинаешь искать причину отсутствия работы. Задача меняется целиком. Пока думаешь, что задание работает плохо, лезешь в его код. Когда выясняется, что оно не работает вовсе, код можно закрыть - в нём ответа нет.
Отсюда первый практический вывод, самый дешёвый в этой статье. История запусков задания отвечает на другой вопрос, чем его статус. Статус говорит, чем закончился последний вызов. История говорит, были ли вызовы вообще. Второе спрашивают гораздо реже, а стоит начинать с него.
Первая версия: задание видит недавний успех и пропускает
Правдоподобное объяснение нашлось сразу, и в этом была его опасность.
В базе есть регистр, куда механизм пишет свои успешные прогоны. Версия звучала так: задание видит там свежую запись за близкую дату, считает, что работа уже сделана, и выходит, ничего не делая. Такое поведение встречается, объясняет ровно то, что мы наблюдали, и закрывает вопрос, не потребовав ни одной проверки.
Проверили в лоб. Удалили запись о недавнем успешном прогоне, руками отправили данные за нужный день, чтобы состояние стало заведомо чистым, и стали ждать.
Четыре дня молчания подряд. Ни одного автоматического запуска. Ни одной новой записи. Механизм, который обязан реагировать на появление работы, не отреагировал ни разу.
Версию убил замер. Рассуждениями её было не сдвинуть, они как раз играли за неё: чем дольше не запускается, тем убедительнее звучит "ну ему просто нечего делать". Четыре дня по календарю - это приговор без права на "может, не успело".
Форма проверки тут важнее самого результата, потому что переносится куда угодно. Мы не доказывали, что задание работает. Мы создали для него работу и посмотрели, сделает ли оно её.
У приёма есть цена, и знать её надо заранее. Создание работы означает вмешательство в данные, и на боевой базе это не всегда безобидно: убрали запись, задание её не восстановило, и теперь у вас минус запись плюс исходная проблема. Объект для эксперимента выбирается такой, потерю которого вы переживёте, и восстановить его руками вы должны уметь до начала. У нас это условие выполнялось, иначе разговор шёл бы про копию базы.
Четыре объяснения, которые пришлось закрыть
Между "версия про недавний успех не подтвердилась" и "нашли причину" лежит неделя. Она ушла на перебор. Привожу его целиком, потому что перебор и есть полезная часть: если у вас задание не запускается, вы пойдёте ровно по этому списку.
Запрет регламентных заданий в кластере 1С. У сервера есть параметр, целиком выключающий регламентные задания для информационной базы. Классика, и проверяется первым делом. У нас он был выключен, то есть задания разрешены.
Константа БСП про работу в модели сервиса. В типовых конфигурациях на библиотеке стандартных подсистем есть настройка, при которой заданиями управляет не сама база. Проверили, оказалось неприменимо: база не в модели сервиса.
Привязка команды к заданию. У регламентного задания есть внутренний идентификатор, связывающий запись с тем, что должно выполняться. Расхождение здесь даёт ровно нашу картину: запись есть, выполнять нечего. Сверили - привязка корректная.
Права на внешние соединения. Механизм ходит наружу, поэтому версия про запрет соединений выглядела разумной. Проверили в двух базах - в проблемной и в соседней, где всё работает. Ноль записей и там и там. Отличия нет, значит это не причина.
Здесь стоит остановиться на приёме, который в этом переборе делал всю работу. Соседняя база с тем же кодом - это контрольный образец, и он дороже любой теории. Каждую версию мы проверяли одним вопросом: отличаются ли этим две базы. "Звучит разумно" тут не аргумент. Всё, что одинаково у работающей и у неработающей, отпадает мгновенно и без обсуждения.
Ложная улика: расписание
Одно отличие между базами всё-таки нашлось, и оно увело расследование в сторону на несколько дней.
В соседней базе задание стояло на простом расписании: один раз в сутки, поздно вечером. И стреляло каждый день, как часы. В нашей - повторяющееся окно: каждый день с утра, несколько часов подряд, с интервалом в час.
Отличие настоящее, объяснение напрашивалось само: значит, платформа как-то иначе отрабатывает повторяющиеся окна, и надо копать туда. Логика безупречная, вывод неверный. Расписание было ни при чём совсем.
Мораль тут не про расписания. Найденное отличие ощущается как найденная причина, и это ощущение обманывает. Две базы отличаются десятком мелочей, и первое отличие, попавшееся под руку, немедленно становится главным подозреваемым - просто потому, что других кандидатов в этот момент нет. Отличие становится причиной только после того, как вы его устранили и поведение изменилось. До этого момента это улика, а не приговор.
Настоящая причина: поле "Имя пользователя"
У регламентного задания есть поле, определяющее, от чьего имени оно выполняется. В нём стояла учётная запись из другой базы - той, откуда обработку когда-то скопировали вместе со всеми настройками.
Механизм копирования тут ключевой, и он бытовой до обидного. Обработка писалась под одну базу, потом понадобилась во второй. Её перенесли целиком, вместе с настройками регламентного задания. Всё, что зависело от базы, поправили: адреса, коды, параметры. Учётную запись в поле "от кого выполняется" не поправил никто, потому что её никто и не вспомнил.
Дальше сессия под это задание просто не стартовала. Не отработала вхолостую - её вообще не было. Отсюда полное отсутствие записей и полное отсутствие ошибок: жаловаться было некому.
Поле поправили, задание пошло само. Разрыв за дни, пока шло расследование, закрыли вручную - 271 пакет, ни одной ошибки, сверка со стороны получателя подтвердила совпадение.
Почему это поле никто не смотрит
Три причины, и все три бытовые.
Задание создаётся один раз, и поле заполняется тогда же - обычно тем, кто в этот момент настраивал систему, и обычно своей учёткой или той, что была под рукой. Дальше про него не вспоминают.
В типовой форме списка этого поля не видно. Видно наименование, использование, расписание и результат последнего запуска. Чтобы понять, под кем задание работает, надо открыть карточку.
И третье, самое обидное: когда с заданием внешне всё в порядке, повода открывать карточку не возникает вообще. Открывают то, что падает.
Добавлю неприятное про себя. Проверка этого поля стоит у меня в двух рабочих чек-листах, по разным системам. В один из них она попала раньше, чем случилась эта история. Грабли были записаны, и это не помешало на них наступить: чек-лист открывают при настройке, а тут переносили готовое.
Отдельное правило про перенос: обработка, скопированная из другой базы, приносит с собой чужие настройки. Всё, что в ней ссылается на пользователя, каталог, адрес или узел обмена, - кандидат на проверку. Не потому что кто-то ошибся, а потому что переносили правильно, вместе с настройками.
Как проверить у себя
Порядок такой, от самого дешёвого.
Посмотреть, были ли автоматические запуски вообще. Не последний результат, а историю. Если механизм ведёт собственный журнал - поднять его целиком и посмотреть на распределение по датам и по авторам записей. Все записи от ручных прогонов - вы нашли ту же болезнь.
Открыть карточку задания и посмотреть поле "Имя пользователя". Дальше три вопроса к тому, что там стоит: существует ли эта учётная запись, не заблокирована ли она, из этой ли она базы. Пустое значение - тоже вопрос: надо понимать, под кем в этом случае идёт выполнение в вашей конфигурации.
Сравнить с базой, где такое же задание работает. Если у вас несколько похожих баз, это самый быстрый путь. Сравнивать по списку: запрет заданий на кластере, настройки библиотеки, привязка команды, учётная запись, расписание. Одинаковое отбрасывать сразу.
Пройтись по остальным заданиям этой базы. Поле, которое однажды заполнили не глядя, с высокой вероятностью заполнено так же и у соседей. Это тот случай, когда починка одного задания без осмотра остальных - половина работы.
Соседняя история про расписание, и она из другого проекта
Сразу оговорю: это другое задание в другой системе, к молчуну выше оно отношения не имеет. Свожу их в одну статью потому, что слепота одинаковая, но склеивать в один инцидент не надо.
Там задание было настроено круглосуточно с интервалом пять минут. Обрабатывать оно должно то, что появляется в рабочее время. Двести восемьдесят восемь запусков в сутки, и большая часть заведомо впустую.
В плане работ по той системе записано перевести его на рабочие дни, 08:00-19:00, интервал 15-30 минут. Пункт на момент написания не закрыт. Арифметика видна и без замера: 288 запусков в сутки против 22-44 в рабочий день, то есть в шесть-тринадцать раз меньше, и пять дней в неделю вместо семи.
Интересна тут зеркальность. Одно задание не запускалось вовсе, второе запускается 288 раз в сутки почти вхолостую. В списке заданий оба выглядят одинаково нормально, и второе даже убедительнее первого. Чем чаще запуск, тем ровнее ряд отметок о выполнении и тем меньше поводов усомниться. Частый запуск покупает иллюзию здоровья за ваши же ресурсы.
Правило, которое я из этого вынес: частота запуска должна соответствовать частоте появления работы. Если задание срабатывает на порядок чаще, чем появляются данные, вы платите процессорным временем и заодно теряете диагностическую ценность собственного журнала.
Что смотреть вместо статуса
Следствие важнее отчёта. Что физически меняется в базе, когда задание отработало правильно: появляется запись, сдвигается дата, уходит документ. Хотя бы одно такое значение вы должны уметь посмотреть за минуту, без разбора журнала регистрации. Именно оно отвечает на вопрос "работает ли". Статус отвечает на другой.
Дата последнего изменения данных, а не дата последнего запуска. В нашем случае вторая величина отсутствовала вовсе, а первая молчала шестнадцать месяцев, и никто их не сопоставлял. Разрыв между "запускалось час назад" и "работало год назад" виден одним взглядом, если обе даты лежат рядом.
Учётная запись, от имени которой идёт выполнение. При каждой правке задания и обязательно при переносе обработки между базами.
Как заставить задание жаловаться, и где это не поможет
Всё перечисленное выше делается снаружи и руками. Дешевле научить задание рассказывать о себе самому.
Отметка о фактической работе. Задание пишет дату и объём только тогда, когда действительно что-то обработало. Хранить можно хоть в константе, хоть в регистре сведений. Место роли не играет, играет различение двух событий: "меня запустили" и "я поработал".
Счётчик холостых запусков. Число подряд идущих запусков, в которых работы не нашлось, обнуляется при первой же реальной работе. Само по себе ничего не чинит, зато превращает молчание в число, а число можно сравнить с порогом.
Порог, после которого пустой запуск перестаёт быть нормой. Тут придётся думать головой, шаблона нет. Для задания, которое разбирает поступления с площадки, десяток пустых запусков подряд в рабочее время уже подозрителен. Для задания, которое закрывает месяц, пустой запуск нормален двадцать девять дней из тридцати.
А теперь честное и главное. В нашем случае ни один из этих трёх приёмов не сработал бы. Все они живут внутри кода задания, а код не выполнялся. Задание, которое не стартовало, не напишет вам ни отметки, ни счётчика, ни предупреждения. Внутренняя диагностика по определению не ловит отказ, случившийся до неё.
Значит, нужен взгляд снаружи, и он ровно один: кто-то должен смотреть на дату последнего изменения данных и сравнивать её с сегодняшним днём. Это может быть отчёт на две строки, может быть проверка в мониторинге, может быть пункт в чек-листе сопровождения. Механизм не важен, важно, что он находится вне того, за чем следит.
Правило шире регламентных заданий. Диагностика внутри объекта видит только те отказы, до которых объект дожил. Всё, что убивает его раньше, остаётся невидимым и ловится исключительно снаружи.
Границы применимости
Скажу прямо, чего в этом разборе нет, потому что материал держится на одном случае.
Не посчитано, во что обошёлся простой. Данные довозили вручную, работа выполнялась, прямых потерь не зафиксировано. Сколько на это ушло человеко-часов за шестнадцать месяцев, никто не считал, и я не буду называть цифру, которой у меня нет.
Не проверено, сколько ещё заданий стоят под чужой учётной записью. Вопрос напрашивается первым, и ответа у меня пока нет. Само задание починено, сплошной осмотр остальных - отдельная работа.
Причина названа по результату, а не доказана изнутри платформы. Поле поправили, задание пошло. Это достаточное основание для практики и недостаточное для утверждения о том, как именно платформа обрабатывает запуск с учётной записью, которой в этой базе нет. Если у кого-то есть точное описание механизма - буду признателен в комментариях.
По расписанию из соседней истории нет замера после изменения. Это пункт в плане работ, выполненного факта за ним пока нет, и говорить об улучшении поведения системы я не имею права.
Интервал 15-30 минут и окно 08:00-19:00 - решение под конкретный процесс. Читать их как рекомендацию нельзя. Ваши цифры выводятся из того, как часто у вас появляются данные, и ниоткуда больше.
Другие наши инструменты диагностики 1С:
- Матрица прав доступа 1С для нейросети - показывает, что именно видно под конкретной учётной записью: пригодится, когда задание всё-таки стартует, но приносит пустоту.
- Чек-ап СУБД под 1С - когда задание работает, но медленно, смотреть надо на регламентные операции самой СУБД, а не на код задания.
- Карта объёмов базы 1С - когда задание чистит данные, а база не худеет, показывает, куда именно ушли гигабайты.
И остался у меня вопрос, скорее организационный. Поле "от кого выполняется" заполняется один раз, обычно при настройке, обычно человеком, который через год уже не работает с этой системой. Есть у кого-нибудь практика периодического пересмотра этого поля по всем заданиям базы - с какой периодичностью и по какому поводу? Разовая проверка после аварии закрывает один случай и никак не мешает появиться следующему.
Вступайте в нашу телеграмм-группу Инфостарт