Интеграции почти никогда не падают громко. Обмен остатками между учётной системой и магазином не выдаёт красное окно на весь экран — он просто перестаёт передавать данные, а всё остальное продолжает работать: сайт открывается, заказы принимаются, менеджеры не жалуются. Обнаруживается это через несколько дней и обычно от клиента, которому продали то, чего нет на складе.
Поэтому сигналов нужно два, и они разной природы. Первый — ошибка обмена: система попыталась передать данные и получила отказ. Второй — тишина: за отведённое время не произошло ни одной операции, хотя должна была. Первый настраивают почти всегда, потому что он очевиден. Второй настраивают редко, потому что для него нужно знать норму, — и именно он ловит самые дорогие случаи.
Ниже — инструкция по настройке обоих сигналов своими силами. Что такое мониторинг и логи вообще и как выглядит эта строка в смете подрядчика, мы разбирали отдельно; как проверить работоспособность обмена руками за час — здесь. Эта статья про то, как сделать так, чтобы проверять руками не приходилось.
Два сигнала и что каждый ловит
Разница между ними не техническая, а смысловая: ошибка сообщает, что конкретная операция не прошла, тишина сообщает, что операций нет вовсе. Второе гораздо хуже, потому что обычно означает, что сломался не документ, а сам механизм обмена.
| Сигнал | Что произошло | Типичная причина | Насколько срочно |
|---|---|---|---|
| Ошибка обмена | Операция выполнена и завершилась отказом | Некорректные данные в одной записи, отсутствующий товар в справочнике, отказ внешнего сервиса | Средне: остальные записи, как правило, продолжают идти |
| Серия однотипных ошибок | Отказ повторяется на всех записях подряд | Истёк токен доступа, сменился формат на стороне партнёра, упёрлись в лимит запросов | Высоко: обмен фактически стоит, хотя формально работает |
| Тишина | За N часов не выполнено ни одной операции | Остановлена служба обмена, не сработало расписание, перезагрузился сервер и сценарий не поднялся | Максимально: обычно означает, что механизм не работает целиком |
| Расхождение количеств | Операции идут, но передано меньше, чем создано | Фильтр по дате съехал, часть записей молча отбрасывается по условию | Высоко и незаметно: ошибок нет, данные теряются частично |
Обмен идёт, журнал зелёный, ошибок ноль — а передаётся тридцать записей вместо трёхсот, потому что условие отбора перестало захватывать часть документов. Ни один контроль ошибок этого не увидит: ошибок нет. Ловится это только сверкой количеств — сколько записей создано в системе-источнике и сколько дошло до приёмника за один и тот же период. Поэтому счётчик событий нужен даже там, где ошибки уже контролируются.
Что приготовить и настроить по шагам
Перед настройкой нужны три вещи: список обменов с ожидаемой частотой, канал, куда пойдут сообщения, и фамилия того, кто по ним действует. Без третьего пункта настройка бессмысленна: оповещения будут приходить в общий чат и там же умирать.
- 1Шаг 1. Завести журнал операций
Каждая операция обмена пишет строку: время, направление, тип, идентификатор записи, результат. Проверяемый результат — за вчерашний день в журнале есть записи и по ним видно, сколько операций прошло успешно, а сколько с отказом. Если журнала нет, всё дальнейшее строить не на чем.
- 2Шаг 2. Посчитать норму
Возьмите журнал за две-три недели и посчитайте число операций по часам и дням недели. Проверяемый результат — таблица нормы: сколько событий бывает в рабочий час, сколько ночью, сколько в выходные. Норму считают по факту, а не назначают по ощущению.
- 3Шаг 3. Настроить сигнал по ошибкам
Оповещение при отказе, но не на каждый: срабатывает при трёх однотипных отказах подряд или при доле отказов выше 10 % за час. Проверяемый результат — искусственно испорченная тестовая запись даёт одно сообщение, а не сорок.
- 4Шаг 4. Настроить сигнал по тишине
Отдельная проверка по расписанию: если за пороговое время событий ноль — сообщение. Проверяемый результат — при остановленной службе обмена сообщение приходит в пределах установленного порога. Это единственный шаг, который ловит полную остановку.
- 5Шаг 5. Настроить сверку количеств
Раз в сутки сравниваются два числа: создано в источнике и принято в приёмнике за прошедшие сутки. Проверяемый результат — при расхождении больше 2 % приходит сообщение с обоими числами. Порог 2 %, а не 0 %: небольшой сдвиг по границе суток — нормальное явление.
- 6Шаг 6. Назначить получателя и проверить доставку
Сообщения идут в канал, который человек читает, и у сигнала есть поимённый ответственный. Проверяемый результат — тестовое сообщение получено конкретным человеком, и он подтвердил это письменно. Не «отправлено», а «получено».
Схема: слева блоки «Учётная система» и «Магазин», между ними блок «Обмен». Обмен пишет в блок «Журнал операций». От журнала вверх три параллельные проверки: «Ошибки: 3 подряд или доля выше 10 % за час», «Тишина: нет событий дольше порога», «Сверка количеств: расхождение больше 2 % за сутки». Все три сходятся в блок «Канал оповещения», от него стрелка к фигуре «Дежурный, поимённо». Сбоку у блока тишины пометка «единственная проверка, ловящая полную остановку». Чертёжный стиль, подписи по-русски.
Пороги нормы: по часам и дням недели
Одно число не работает. Порог «нет событий два часа» ночью в воскресенье сработает у всех, кто его так задал, и через неделю сигнализацию отключат — не потому, что она плохая, а потому, что она врёт. Норма всегда привязана к календарю компании.
| Период | Ожидаемая частота | Порог тишины | Куда сообщать |
|---|---|---|---|
| Будни, 9:00–19:00 | 30–60 событий в час | 1 час | Дежурному сразу |
| Будни, 19:00–23:00 | 5–15 событий в час | 3 часа | Дежурному сразу |
| Будни, ночь | 0–3 события в час | Не проверяем | Копится до утренней сводки |
| Суббота, рабочий день склада | 10–25 событий в час | 3 часа | Дежурному по графику выходного дня |
| Воскресенье и праздники | 0–5 событий в час | 8 часов | Утренняя сводка, звонок только при полной тишине сутки |
| Первый рабочий день после праздников | Пик, до 120 событий в час | 1 час | Дежурному сразу, порог по ошибкам временно снижен |
Две настройки, которые экономят больше всего нервов. Первая — календарь производственных дней: без него каждый праздник даёт ложную тревогу, а каждый рабочий выходной — пропущенный сбой. Вторая — утренняя сводка: всё, что накопилось за ночь и не является аварией, приходит одним сообщением в начале рабочего дня. Ночью будят только полной тишиной там, где ночью обмен обязан идти.
Текст оповещения: шесть полей
Сообщение «Ошибка интеграции» не даёт ни оценить масштаб, ни начать действовать: получатель всё равно идёт разбираться вручную, то есть теряет те самые минуты, ради которых сигнализацию и ставили. Рабочее сообщение отвечает на шесть вопросов и помещается в пять строк.
- Какая система и какое направление. Не «интеграция», а «обмен остатками: 1С:УТ → магазин». В компании обменов обычно пять-шесть, и первые тридцать секунд уходят на догадки.
- Что именно случилось. Тип сигнала словами: серия отказов, тишина, расхождение количеств. Техническое сообщение системы прикладывается ниже, но первой строкой идёт человеческая формулировка.
- Когда началось. Время первого отказа или последнего успешного события, а не время отправки сообщения. Разница между ними и есть то, сколько вы уже потеряли.
- Сколько записей затронуто. Число, а не «некоторые». Одна застрявшая накладная и триста застрявших заказов требуют разной скорости реакции.
- Что делать первым. Одна конкретная строка: «проверить, запущена ли служба обмена», «обновить токен доступа», «сообщить подрядчику». Не инструкция на страницу, а первое действие.
- Кому эскалировать, если не помогло. Имя и способ связи. Без этого поля сообщение в нерабочее время просто зависает до утра.
Практический ориентир по длине: сообщение читается за 15 секунд с экрана телефона. Всё, что длиннее, читают по диагонали, а через месяц перестают открывать вовсе. Технические подробности — трассировку, идентификаторы, полный ответ сервиса — кладут по ссылке на журнал, а не в само сообщение.
Сравнение в две колонки, оба — карточки сообщений на экране телефона. Левая, перечёркнутая: одна строка «Ошибка интеграции. Код 500». Правая, отмеченная галочкой, пять строк: «Обмен остатками: 1С:УТ → магазин», «Тишина: нет событий с 19:40 пятницы», «Затронуто: 312 позиций остатков», «Первое действие: проверить, запущена ли служба обмена», «Не помогло — Сергей, подрядчик, до 22:00». Под правой карточкой подпись «читается за 15 секунд». Чертёжный стиль, подписи по-русски.
Дежурство, защита от шума и учебный сбой
Настроенная сигнализация умирает по двум причинам: её либо некому получать, либо она кричит слишком часто. Обе лечатся заранее и обе стоят дешевле, чем любая техническая часть.
- Один поимённый дежурный, а не общий чат. У сигнала есть получатель, и он знает, что он получатель. В общем чате из двенадцати человек сообщение видят все и не реагирует никто.
- График на выходные и отпуска. Заранее, а не в момент сбоя. Если подменить некем, честнее снизить требования: пусть в выходные сигналы копятся до понедельника — это осознанное решение, а не иллюзия контроля.
- Что считается реакцией. Не «увидел», а «ответил в канал: взял в работу». Ориентир: 30 минут в рабочее время, до начала следующего рабочего дня в остальное. Формулируется одной строкой и вешается рядом с условиями поддержки.
- Повтор перед оповещением. Прежде чем поднимать тревогу, система пробует ещё раз через минуту и через пять. Большая часть отказов внешних сервисов — временные, и без этой настройки половина сообщений будет про уже исчезнувшую проблему.
- Группировка однотипного. Триста одинаковых отказов — одно сообщение с числом, а не триста сообщений. Это самая важная настройка из всех: именно поток одинаковых сообщений и приучает игнорировать канал.
- Тихие часы и повторное напоминание. Ночью не будят по несрочному, но неотработанный сигнал напоминает о себе утром, а не исчезает. Забытый сигнал хуже неотправленного.
И проверка самой сигнализации — раз в квартал, полчаса. Порядок простой: предупредите дежурного, что учение будет на этой неделе, но не говорите когда; остановите один обмен на время, превышающее порог; засеките, пришло ли сообщение, кому и через сколько; верните всё обратно и запишите три числа — время до сигнала, время до реакции, время до восстановления. Если сообщение не пришло, вы только что нашли поломку, которая иначе обнаружилась бы в худший момент. За первый год такое учение находит проблему примерно в половине случаев: чаще всего бот выкинули из группы или сменился телефон дежурного.
Что пойдёт не так
Шесть сообщений, которые вы увидите в первые же месяцы, и что они означают на самом деле.
- 401 Unauthorized или Invalid token. Истёк или отозван токен доступа. Обмен встаёт целиком и молча, ошибки при этом идут одинаковые — идеальный случай для сигнала по серии однотипных отказов. Заведите отдельное напоминание за неделю до истечения срока токена.
- 429 Too Many Requests. Упёрлись в лимит запросов внешнего сервиса. Часть записей при этом теряется безвозвратно, если не настроен повтор. Лечится не увеличением частоты, а пакетной передачей и паузами.
- Connection timed out. Внешний сервис не ответил вовремя. Почти всегда временно, поэтому и нужен повтор перед оповещением: без него это будет самый шумный сигнал в системе.
- Duplicate key value violates unique constraint. Повторная отправка того же документа — обычно после того, как первая попытка прошла, но ответ не дошёл. Сигнал полезный: он показывает, что обмен не различает «не отправлено» и «отправлено, но неизвестно».
- Ноль записей без единой ошибки. Самый опасный случай: обмен отработал, отчитался успехом и передал пустоту. Ловится только счётчиком и сверкой количеств; никакой контроль ошибок его не увидит.
- Оповещение не пришло вообще. Бота удалили из группы, сменился номер дежурного, кончился баланс у сервиса рассылки сообщений. Обнаруживается исключительно учебным сбоем — других способов узнать об этом заранее не существует.
Сколько это стоит
Модельная компания: интернет-магазин, три обмена — остатки, заказы, документы. Ставка инженера-подрядчика 3 000 ₽/час, руководителя направления со стороны заказчика — 1 800 ₽/час.
Теперь цена одного тихого сбоя. Обмен остатками встал в пятницу вечером, заметили в среду утром — три рабочих дня без обновления остатков в модельном магазине с потоком 40 заказов в день.
В расчёт намеренно не заложены отменённые клиенты, которые больше не вернутся, и отзывы после отмены заказа — эти потери реальны, но посчитать их честно нельзя, а гадать в смете не стоит. Даже без них арифметика сходится: два тихих сбоя в год — и настройка окупилась. При этом ни один из перечисленных шагов не требует отдельной системы мониторинга: всё делается средствами уже работающей интеграции и одного мессенджера.
Когда сигнализация не нужна
Три ситуации, в которых настройка оповещений — потраченные часы, и лучше сказать это прямо.
- Обмен запускается вручную по факту. Если сотрудник сам нажимает кнопку выгрузки раз в неделю и сразу видит результат, контроль тишины не нужен: тишину замечает человек. Достаточно, чтобы ошибка была видна на экране в момент запуска.
- Цена простоя ниже стоимости настройки. Обмен справочником контрагентов, который может постоять три дня без последствий. Здесь честнее раз в неделю посмотреть журнал, чем строить дежурство.
- Некому получать сигнал. Если в компании нет ни своего инженера, ни договора на сопровождение, оповещения будут приходить в пустоту. Тогда правильное решение — не сигнализация, а передача наблюдения на поддержку или регулярная ручная проверка по чек-листу.
И общее правило, которое стоит держать в голове при любом разговоре с подрядчиком: спросите, что произойдёт, если обмен встанет в пятницу вечером. Если ответ — «мы увидим в понедельник в журнале», наблюдения у вас нет, независимо от того, что написано в договоре словом «мониторинг».
Интеграция сообщает о своей смерти молчанием. Слушать надо не ошибки, а тишину.
