Обмен с 1С почти никогда не падает громко. Громкая поломка — это когда рвётся канал, регламентное задание валится с ошибкой, а подрядчику приходит письмо. Такое чинится за час и стоит копейки. Дорого обходится тихий отказ: пять потоков из шести продолжают ходить, а шестой перестал, никто ничего не заметил, и через неделю выясняется, что в 1С нет заказов с сайта за всю прошлую неделю.
Дальше — модельная компания, к которой мы будем возвращаться: оптовик на 1С:УТ 11, обмен «сайт ↔ 1С» и «1С ↔ CRM», около 400 заказов в месяц, то есть 18 заказов в рабочий день. Обмен заказами тихо встал и простоял шесть рабочих дней, пока об этом не сказал клиент. Все расчёты ниже — по ставке 3 500 ₽/час профильного интегратора, как в остальных материалах этого раздела.
Разбираем по порядку: шесть причин остановки и часы на каждую, почему зелёный статус задания вводит в заблуждение, три метрики, которые дают сигнал за сорок минут, и что делать в первый час после падения — своими силами и с подрядчиком.
Шесть причин, по которым обмен встаёт
Механизмов обмена у 1С несколько — HTTP-сервисы, OData, планы обмена, файловая выгрузка, готовые модули; мы разбирали их устройство и цену в материале про способы обмена с 1С. Ломаются они по-разному, но причин остановки на практике шесть, и они закрывают подавляющее большинство обращений.
| Причина | Как выглядит снаружи | Где смотреть в 1С | Часы на восстановление |
|---|---|---|---|
| Истёк пароль пользователя обмена или токен внешнего сервиса | Внешняя система «молчит», 1С работает нормально | Журнал регистрации, события ошибок аутентификации по пользователю обмена | 1–2 часа |
| Регламентное задание выключено после обновления или перезапуска сервера | Ошибок нет вообще, данных тоже нет | Администрирование → Обслуживание → Регламентные и фоновые задания | 0,5–1 час |
| Исчерпан лимит запросов на стороне партнёра | Часть данных приходит, часть теряется без видимой закономерности | Журнал обмена: ответы об ограничении частоты и отказы по времени ожидания | 3–6 часов |
| Изменился формат данных после релиза конфигурации или партнёра | Старые документы ходят, новые падают | Сравнение контракта данных: состав полей, типы, обязательность | 6–16 часов |
| Кончилось место на диске или разросся журнал регистрации | База тормозит, задания вылетают по времени ожидания | Размер каталога базы, размер журнала регистрации, свободное место тома | 2–4 часа |
| Изменились права пользователя обмена | Данные читаются, но не записываются | Профили групп доступа пользователя обмена, ограничения на уровне записей | 1–3 часа |
Существенная деталь: пять причин из шести — это не программирование. Пароль, выключенное задание, место на диске, права и лимит партнёра чинит администратор или грамотный пользователь с правами администратора. Программист нужен только на четвёртой строке, когда изменился контракт данных. Отдельный разбор того, как релиз конфигурации ломает обмен и сколько стоит адаптация, есть в статье про обновление, которое сломало обмен.
Сравнение в две колонки. Левая, широкая, подписана «Чинит администратор»: пять карточек — «Истёк пароль или токен — 1–2 ч», «Выключено регламентное задание — 0,5–1 ч», «Исчерпан лимит партнёра — 3–6 ч», «Кончилось место на диске — 2–4 ч», «Изменились права пользователя обмена — 1–3 ч». Правая, узкая, подписана «Нужен разработчик»: одна карточка «Изменился формат данных — 6–16 ч». Под колонками подпись: «Дорого не чинить, дорого не замечать». Чертёжный стиль, подписи по-русски.
Почему «Выполнено» у регламентного задания ничего не доказывает
Первое, что делает человек, когда обмен встал, — открывает список регламентных заданий и видит там зелёные отметки о выполнении. Из этого делается вывод, что «в 1С всё в порядке, проблема на той стороне», и следующие два дня уходят на переписку с подрядчиком сайта. Вывод неверный, потому что отметка о выполнении означает ровно одно: процедура отработала и не выбросила исключение.
Процедура при этом могла отработать на пустом списке. Отбор в запросе перестал находить документы, потому что после релиза у них другой статус; узел плана обмена не помечает изменения, потому что его состав обнулился; выгрузка ушла в каталог, который переименовали при переезде сервера. Во всех трёх случаях задание честно завершится с отметкой «Выполнено», и обмен будет стоять.
У задания есть собственный флаг «Включено» и есть общий переключатель регламентных заданий в информационной базе, который выключают на время обновления и забывают вернуть. В списке при этом видны прошлые успешные выполнения, а новых просто нет — и именно отсутствие новых строк заметить труднее всего. Отдельно проверяйте не статус последнего запуска, а дату и время последнего запуска.
Правильная проверка одна: сквозной документ. Создаётся тестовый заказ на технического контрагента, и проверяется, что он появился на другой стороне с нужными реквизитами, а статус вернулся обратно. Это единственное доказательство, что маршрут жив целиком, а не по частям. Общий контур наблюдения за интеграциями — сигналы, пороги, договор поддержки — мы разбирали в материале про мониторинг интеграций; здесь остановимся на том, что специфично именно для 1С.
Три метрики, которые превращают неделю в сорок минут
Наблюдать за обменом целиком не нужно и дорого. Достаточно трёх чисел, которые снимаются с самой 1С и с промежуточного сервиса, если он есть. Все три считаются автоматически, никого не отвлекают и дают сигнал раньше, чем поломку заметит первый клиент.
- Время с последнего успешного обмена по каждому потоку отдельно. Не «обмен работает», а «заказы — 8 минут назад, остатки — 12 минут назад, статусы — 6 дней назад». Порог тревоги — три интервала расписания: если обмен идёт каждые 15 минут, сигнал уходит через 45 минут молчания. Именно эта метрика ловит тихий отказ одного потока из шести.
- Длина очереди: сколько записей помечено к выгрузке и не выгружено. В планах обмена это число изменений в узле, в очереди промежуточного сервиса — число необработанных сообщений. Порог — превышение среднего дневного объёма: при 18 заказах в день очередь в 40 непроведённых записей означает, что приём встал, даже если отправка идёт.
- Доля ошибок за час. Одна ошибка — норма, сеть моргает у всех. Порог — больше 5 % неудачных попыток за час или три подряд по одному и тому же методу. Эта метрика отделяет ситуацию «партнёр ограничил частоту» от ситуации «мы отправляем неверные данные»: в первом случае ошибки размазаны, во втором собраны на одном методе.
Все три метрики бесполезны без журнала обмена, в котором видно, какая конкретно запись не прошла и почему. Как устроен такой журнал, какие шесть полей в нём обязательны и как он за десять минут закрывает спор «мы отправили — вы не получали», разобрано в журнале обменов. Без него метрики скажут «сломалось», но не скажут «что именно».
Две горизонтальные ленты времени одна под другой. Верхняя, длинная, подписана «Без наблюдения»: отметки «0 — обмен встал», «1–5 день — заказы копятся мимо 1С по 18 в день», «6 день — позвонил клиент, 108 заказов вводятся руками задним числом», «6 день + 6 часов — подрядчик нашёл причину». В конце подпись «66 420 ₽». Нижняя, короткая, подписана «С тремя метриками»: отметки «0 — обмен встал», «45 минут — сигнал ответственному», «40 минут разбора — причина найдена». В конце подпись «28 000 ₽ разово, 3 500 ₽/мес». Чертёжный стиль, подписи по-русски.
Шесть дней молчания в рублях
Считаем прямые потери на модельной компании. Заказы с сайта шесть рабочих дней не попадали в 1С: 6 × 18 = 108 заказов. Часть из них менеджеры ввели руками, когда спохватились; часть клиентов не дождалась подтверждения и ушла; часть товара продалась из остатка, которого физически не было, потому что остатки на сайт тоже не уезжали.
Контур наблюдения — это 8 часов работы: три метрики, пороги, оповещение и сквозной тестовый документ по расписанию. 28 000 ₽ разово и около 3 500 ₽/мес на хостинг и присмотр. Он дешевле одной тихой поломки в 2,4 раза, и это без учёта того, что часть потерянных заказов не восстанавливается вообще. Отдельная статья потерь — задвоенные документы, которые появляются, когда обмен восстановили неаккуратно: этот сценарий и его цену мы разбирали в материале про дубли и пересортицу при обмене.
Кому уходит оповещение и что он делает в первый час
Оповещение на общий ящик вроде «info@» или в общий рабочий чат не работает по одной причине: у сообщения нет адресата, а значит, нет и обязанности. Письмо прочитают трое, каждый решит, что реагирует кто-то другой, и через неделю письмо найдут в архиве. Адресат должен быть один и должен быть человеком, а не должностью: конкретное имя, конкретный канал, конкретное обязательство отреагировать в течение рабочего часа.
Дальше — порядок действий на первый час. Он рассчитан на администратора или ответственного пользователя без участия подрядчика: пять шагов из шести приводят к решению своими силами.
- 10–10 минут: понять, встало целиком или частично
Смотрим время последнего успешного обмена по каждому потоку. Если молчит один поток, а остальные идут — это не канал и не сервер, это конкретный метод. Если молчат все — проверяем доступность базы и сети, дальше по общему сценарию.
- 210–20 минут: журнал регистрации по пользователю обмена
Фильтр по пользователю обмена за период молчания и по уровню «Ошибка». Здесь видны отказы аутентификации, отказы прав доступа и превышение времени ожидания. Пустой журнал за период — тоже результат: значит, обмен не запускался вовсе.
- 320–30 минут: регламентные задания и планировщик
Проверяем не статус, а дату последнего запуска задания и общий переключатель регламентных заданий в базе. Здесь же — свободное место на диске и размер журнала регистрации: две самые частые причины вылета заданий по времени ожидания.
- 430–40 минут: внешняя сторона
Срок действия сертификата и токена, доступность адреса партнёра, ответы об ограничении частоты запросов. Если партнёр ограничил частоту, обмен восстановится сам после паузы, но объём накопленной очереди надо разбирать отдельно и медленнее обычного.
- 540–60 минут: решение — сами или подрядчик
Пароль, задание, место, права и лимит закрываются своими силами. Если журнал показывает отказ по составу или типу полей — это изменившийся контракт данных, и дальше нужен разработчик: 6–16 часов работы и обязательно тестовый контур, а не правка на боевой базе.
- 6После восстановления: разобрать очередь, а не стереть её
Накопленные записи проводятся порциями с проверкой на дубли по номеру и дате. Восстановление обмена без сверки — самый быстрый способ получить задвоенные заказы и расхождение остатков в тот же день.
Схема сверху вниз. Верхний блок «Сигнал: поток молчит 45 минут» с подписью «адресат — конкретный человек, не общий ящик». Ниже четыре блока подряд со стрелками: «Какой поток встал (0–10 мин)», «Журнал регистрации по пользователю обмена (10–20 мин)», «Регламентные задания, планировщик, место на диске (20–30 мин)», «Токен, сертификат, лимит партнёра (30–40 мин)». Из последнего блока развилка на два: слева «Чиним сами: 0,5–4 часа» (пароль, задание, место, права), справа «Разработчик: 6–16 часов» (изменился контракт данных). Внизу общий блок «Разбор очереди с проверкой на дубли». Чертёжный стиль, подписи по-русски.
Когда наблюдать не за чем
Отдельный контур наблюдения нужен не всем, и продавать его вместе с любой интеграцией — нечестно. Есть три ситуации, в которых мы сами советуем ограничиться одним оповещением об ошибке и не тратить 28 000 ₽.
- Обмен ходит раз в сутки и возит меньше 30 документов в день. Тихая остановка обнаружится на следующее утро при обычной работе, и цена суток простоя сопоставима с ценой самого контура за год. Достаточно письма об ошибке и привычки смотреть на дату последней выгрузки.
- Обмен односторонний и не влияет на деньги. Выгрузка справочника номенклатуры на витрину или ночная отправка отчёта — остановка такого потока не создаёт ни пересортицы, ни потерянных заказов. Проверка раз в неделю глазами обходится дешевле любой автоматики.
- У вас нет человека, который отреагирует. Метрики без адресата превращаются в ещё один поток уведомлений, который через месяц отключают. Сначала назначается ответственный и фиксируется его обязательство по времени реакции, и только потом ставится наблюдение. В обратном порядке это выброшенные деньги.
И последнее. Все шесть причин из таблицы — не про качество интеграции, а про эксплуатацию. Обмен, написанный идеально, встанет ровно так же, когда у пользователя обмена истечёт пароль. Поэтому договор поддержки и наблюдение — это не надстройка над интеграцией, а её вторая половина, и закладывать её в бюджет надо в тот же день, когда подписывается смета на саму связку. Как считается эта смета целиком, разобрано в материале о цене интеграции с 1С.
Обмен ломается не в момент разработки, а в момент эксплуатации. Значит, и деньги на него нужны не разово, а ежемесячно.
