Выгрузка 1С по расписанию не работает, хотя все задания зелёные
Иван Недомолков · Dərc edilib: · Yenilənib:
Симптом знаком любому, кто сопровождает обмены: в приёмнике данные за прошлую неделю, пользователи жалуются на старые остатки, а по всем журналам ночная выгрузка отработала. Планировщик зелёный, регламентные задания в 1С со статусом “Выполнено успешно”, файлы на месте и с сегодняшней датой.
Дальше обычно начинается перебор подозреваемых: сеть, права, блокировки, место на диске. Перебор может занять день и ничего не дать, потому что искать надо в другом месте. Ниже методика из пяти проверок, которая локализует поломку за час. Она собрана по следам реального аудита, где цепочка выгрузки простояла 35 дней под полностью зелёной отчётностью.
Сначала развести три разных утверждения
Пока они склеены, диагностика ходит по кругу.
- “Задание запустилось”. Это факт вызова: планировщик или менеджер регламентных заданий дошёл до строки запуска.
- “Задание отработало”. Процесс завершился и код завершения не сигналит об ошибке.
- “Работа сделана”. Результат существует и построен на свежих данных.
Между ними нет автоматической связи. Задание может запуститься и не отработать. Может отработать и ничего полезного не сделать. Штатные средства контроля почти всегда показывают первое утверждение, иногда второе. Бизнесу нужно третье, и именно его никто не измеряет.
Все пять проверок ниже - это способы добраться до третьего утверждения, минуя первые два.
Проверка 1. Матрица прогонов, а не последний запуск
Открыть последний запуск и убедиться, что он “прошёл”, бесполезно: одиночный успешный запуск неотличим от нормы даже тогда, когда половина цепочки мертва.
Вместо этого собирается таблица за период: строки - шаги цепочки, столбцы - даты плановых прогонов, в ячейках факт старта по журналу. Источники: журнал планировщика Windows (History у задачи либо канал Microsoft-Windows-TaskScheduler/Operational), журнал регистрации 1С по событиям фоновых заданий, лог самого скрипта, если он есть.
Такая таблица читается мгновенно. Вот матрица из упомянутого аудита, шесть плановых прогонов за пять недель:
| Шаг цепочки | Стартов из 6 |
|---|---|
| Инвентаризация | 6 |
| Подготовка данных | 0 |
| Обработка | 6 |
| Выгрузка | 0 |
| Проверка | 6 |
Форма отказа здесь важнее самого отказа. Устойчивый ноль по конкретным позициям при полном счёте у соседей означает: эти шаги ни разу не начинали выполняться, управление до их логики не доходило. Копать надо строку запуска - синтаксис команды, параметры, окружение. Разбирать внутренности шага бессмысленно.
Случайные сбои выглядят иначе: два из шести здесь, четыре из шести там. Такой разброс ведёт к ресурсам - сеть, блокировки, таймауты. Ноль и разброс лечатся в разных местах, и матрица разводит их до того, как потрачено время.
Проверка 2. Возраст данных, а не дата файла
Самая коварная ситуация из возможных: шаг честно запускается, честно отрабатывает и честно кладёт результат. Только исходные данные для него давно не обновляются, потому что готовивший их шаг стоит.
В том же аудите шаг обработки отработал все шесть раз без единой ошибки. При этом срез, по которому он работал, замер 10 июня - его перестал обновлять шаг с нулём в матрице. На день проверки результату шёл 41-й день, и всё это время файл выгрузки имел свежую дату, правдоподобный размер и нулевой код возврата.
Дата файла отвечает на вопрос “когда файл записали”. На вопрос “насколько актуально то, что внутри” она не отвечает совсем. В проводнике видна только первая, поэтому их путают постоянно.
Практически проверка выглядит так: открыть сам результат и найти в данных максимальную дату документа, среза, записи. Сравнить с ожидаемой. Для обмена 1С это максимальная дата объекта в пакете, для файловой выгрузки - максимум по датам строк, для загрузки в приёмник - момент последнего реально изменённого объекта. Пять минут запросом, и это единственная проверка из пяти, которая напрямую измеряет “работа сделана”.
Проверка 3. Кодам возврата нельзя верить, пока их не проверили
Контроль по кодам возврата стоит на допущении, что коды правдивы. Допущение стоит проверить до того, как на него опираться: в разобранном случае из трёх исполняемых файлов цепочки врали все три, причём в обе стороны. Один возвращал ошибку при полностью сделанной работе (неэкранированные скобки в выводе внутри условного блока), два других возвращали ноль при внутреннем падении - ошибка просто не доезжала до внешнего кода завершения.
Мониторинг, настроенный поверх таких кодов, показывал бы картину строго наоборот: тревога там, где всё сделано, тишина там, где пять недель ничего не происходит.
Проверяется это за один заход. Запустить шаг на заведомо провальном сценарии (подсунуть несуществующий путь, отключить приёмник) и посмотреть код. Запустить на заведомо успешном и посмотреть ещё раз. Если хотя бы одна пара не сходится, сначала чинятся коды, потом настраивается контроль.
Причина такого дрейфа обычно одна: код возврата никто не читал с момента написания скрипта, и величина, на которую никто не смотрит, свободно уезжает куда угодно.
С HTTP-обменами то же самое, только вместо кода возврата код ответа. У нас пакетная архивация писала FAILED на операциях, которые на деле применились, а ответ 403 означал “уже сделано”. Как отличать такие ответы и когда повтор после таймаута плодит дубли, разобрано в статье о таймауте в обмене с внешним сервисом.
Проверка 4. Ручные запуски маскируют простой
Файл, созданный человеком вручную, в файловой системе неотличим от файла, созданного по расписанию. Это ломает диагностику неожиданным образом: задание может месяц не запускаться по расписанию, но одного доброжелательного “запустил руками, файл появился, вопрос закрыт” достаточно, чтобы внешние признаки поломки исчезли.
В аудите нашлось смежное задание ровно в таком состоянии: по расписанию ноль стартов за месяц, единственный файл за период сделан ручным запуском. Задание выглядело живым.
В 1С такая маскировка бывает долгой. У одного регламентного задания мы нашли 580 записей истории, все от ручных прогонов, и ни одного автоматического запуска за шестнадцать месяцев. Порядок проверки для этого случая, со скриптом по всем заданиям базы, собран в разборе регламентного задания, которое не выполняется. Если заданий в базе десятки, ручные запуски от автоматических отделяет обработка-вердикт по регламентным заданиям: она же называет, что мешает автозапуску, будь то флаг на кластере или пользователь, которого нет в базе.
Ручной обход чинит симптом ровно настолько, чтобы никто не пошёл искать причину. Отсюда две привычки, которые стоят дёшево и экономят недели: любой ручной запуск помечается (в имени файла, в логе, в комментарии к заданию), а при диагностике происхождение последнего результата проверяется отдельно - по журналу запусков, не по наличию файла.
Проверка 5. Контролёр тоже ломается
Если в цепочке есть проверочный шаг, он попадает под подозрение наравне с рабочими. У него неприятное свойство: его собственная поломка выглядит как его нормальная работа - ещё одна зелёная строка в отчёте.
В разобранном случае контрольный шаг стабильно упирался в таймаут, ни разу не доводил проверку до конца и все шесть прогонов рапортовал успех. Механизм, который следит за другими и за которым не следит никто, со временем вырабатывает только зелёный цвет.
Проверка та же, что и у рабочих шагов: подсунуть контролёру заведомо сломанное состояние и убедиться, что он его видит. Если нет - строка “проверка пройдена” в отчётах ничего не значила всё это время.
Как это выглядело вживую
Короткая сводка того самого аудита, по мотивам которого собрана методика. Цепочка из пяти шагов под планировщиком, каждый шаг по расписанию, формальная сверка расписания с журналом за пять недель.
- Два шага из пяти не стартовали ни разу: опечатка в переносе длинной команды на следующую строку, которая проявлялась только в среде планировщика. В интерактивной консоли та же конструкция работала, поэтому проверка руками дефект не ловила.
- Ошибка всё это время лежала в потоке ошибок планировщика - отдельно от кода возврата, куда никто не заглядывал.
- Шаг обработки 41 день строил результат по неизменному срезу.
- Коды возврата врали у трёх файлов из трёх.
- Проверочный шаг молча умирал по таймауту и рапортовал успех.
Полный разбор этой истории с механикой каждого отказа - в статье “Выгрузка данных не запускалась полтора месяца. Все запуски отчитались успехом” на Инфостарте. Здесь из неё взята только методика.
Что поставить на постоянный контроль
Разовый аудит закрывает сегодняшний вопрос. Чтобы не проводить его каждые полтора месяца, контроль переводится с факта запуска на свежесть результата.
Метрика - возраст данных. Разница между текущим временем и отметкой актуальности внутри результата. Это единственное число, которое отвечает на вопрос бизнеса.
Порог - две пропущенные итерации. Одна пропущенная итерация тревогу не поднимает: слишком узкий порог топит дежурного в ложных срабатываниях, и через месяц алерт закрывают не глядя. Две подряд - отказ, что бы ни говорил планировщик.
Матрица прогонов - раз в неделю. Пять минут на сводную таблицу по журналу. Ноль в строке виден мгновенно, на одиночных запусках он не виден вообще.
Правдивость кодов возврата - перед настройкой любого алертинга и после каждой правки скриптов. Дешевле всего закрывается тестовым заданием планировщика: правка пакетного файла прогоняется через задание, заведённое под тем же пользователем и с теми же правами, что боевое. Оно ловит и кавычки в путях, и переносы строк - весь класс дефектов, которые в интерактивной консоли не воспроизводятся.
Где это касается 1С напрямую
Всё выше применимо к регламентным заданиям 1С без поправок. Статус “Выполнено успешно” в журнале фоновых заданий - это утверждение номер два, “процесс завершился без исключения”. Задание, которое отработало по пустой выборке, потому что предыдущее звено не подготовило данные, получит тот же статус. Обмен, который сформировал пакет по старому срезу, тоже.
Поэтому у обменов и выгрузок контролировать стоит момент последнего реально загруженного объекта в приёмнике и возраст данных в пакете, а не статусы заданий. Как выстроить такой контроль на постоянной основе - с метриками, порогами и оповещениями в Telegram - мы разбираем в рамках услуги мониторинга 1С и СУБД. Если же регламентное задание не молчит, а честно тормозит и не влезает в окно, это другая болезнь - про неё у нас есть отдельный разбор оптимизации регламентного задания без переписывания.
Если обмен вернул старое значение
Успех передачи не подтверждает правильность каждого поля. Если после ручной правки реквизит снова стал прежним, сохраните снимки до и после очередного обмена, идентификатор объекта и время изменения. Совпадение по времени задаёт направление поиска, но не доказывает, какой обработчик записал значение.
Проверьте все источники заполнения: значение по умолчанию, модуль сервиса, обработчик загрузки и преобразование в тексте запроса. Найденная константа в одном месте не означает, что остальные пути свободны от неё. Отдельно установите, откуда текущий запуск читает правила обмена. Изменение неиспользуемого макета не повлияет на фактическую загрузку. Что в рабочем файле правил выгружается, как объект ищется в приёмнике и где в правилах лежит код, показывает разбор правил обмена КД 2.
В контрольный набор включите уже существующий объект, новый объект и повторную передачу того же пакета. Для каждого запишите ожидаемое значение и источник его получения. Исключения, например служебные карточки, согласуйте отдельно. Если источник возврата не установлен, так и укажите в акте проверки.
При регулярной выгрузке таблиц дополнительно проверьте сохранение и приёмку XLSX. При сопоставлении продаж и расходов маркетплейса нужны также контрольные сверки расчёта OZON: успешная загрузка с неверным соответствием товаров даёт правдоподобный ошибочный отчёт.
