Интеграция теряет заявки не в момент аварии, а в обычный вторник. Отправитель послал данные, получатель в этот момент был занят или отвечал медленнее обычного, отправитель не дождался и пошёл дальше. Ошибки нет ни у кого: у первой системы заявка отмечена как отправленная, у второй её просто нет. Клиент, который заполнил форму, не узнает об этом никогда — он решит, что вы не перезвонили.
Это и есть последствие обмена, написанного «в один проход»: отправил — и забыл. На демонстрации такой обмен работает идеально, потому что обе системы в этот момент свободны и отвечают за доли секунды. Разница между ним и надёжным обменом видна не в день приёмки, а на третьем месяце эксплуатации, когда кто-то замечает, что в CRM заявок меньше, чем в статистике сайта.
Дальше — разбор для случая, когда обмен у вас уже стоит и уже работает. Как именно он теряет данные, как проверить это за полчаса, не привлекая подрядчика, и во что обходится дошить недостающее задним числом.
Пять способов, которыми работающий обмен теряет данные
Все пять выглядят одинаково со стороны бизнеса — «заявка не дошла» — и совершенно по-разному внутри. Смысл таблицы в том, чтобы по внешнему симптому понять, какой именно из пяти сбоев у вас, и не чинить не то.
| Сбой | Что видит бизнес | Что при этом в системе | Через сколько замечают |
|---|---|---|---|
| Таймаут: получатель не ответил за отведённое время | Единичные заявки пропадают без всякой закономерности | Отправитель считает отправку выполненной, у получателя записи нет | Недели или никогда — до первой сверки счётчиков |
| Ошибка на стороне получателя: сервис вернул отказ | Пропадают заявки за конкретный отрезок времени, обычно утро или вечер | В журнале есть код отказа, но никто его не читает | 1–3 дня, если кто-то смотрит журнал |
| Повторная отправка без ключа: сообщение ушло дважды | В CRM две одинаковые сделки, менеджеры звонят клиенту по очереди | Обе записи корректны, у обеих разные внутренние номера | Сразу, но чинится вручную и бесконечно |
| Изменившийся формат ответа после обновления смежной системы | Часть полей приходит пустыми: заявка есть, суммы или адреса нет | Обмен идёт, ошибок нет, разбор находит только несовпавшие имена полей | 1–2 недели, обычно от бухгалтерии |
| Просроченный токен или сменённый пароль доступа | Обмен останавливается целиком и одномоментно | Отказ по правам доступа, индикаторы доступности при этом зелёные | 2–3 суток — дольше всего, потому что «сервис же отвечает» |
Четвёртая строка — единственная, у которой есть внешняя причина: смежную систему обновили, и формат ответа поехал. Это отдельный сюжет, который лечится регламентом предупреждения, а не обвязкой; мы разбирали его в материале про то, что делать, когда обновление ломает обмен. Остальные четыре строки — следствие того, что в смете не было строки на обработку сбоев.
Карта маршрута из четырёх узлов слева направо: «Форма на сайте» → «Прослойка обмена» → «CRM: сделка» → «Учётная система: заказ». На стрелках между узлами отмечены пять точек отказа красными засечками с подписями: «таймаут», «отказ получателя», «повторная отправка — дубль», «изменившийся формат полей», «просроченный токен». Под каждой засечкой мелкая подпись, через сколько её замечают: «недели», «1–3 дня», «сразу», «1–2 недели», «2–3 суток». В стороне отдельный блок «Очередь с повторами» пунктиром, подписанный «этого узла в смете не было».
Проверка за 30 минут: три запроса к вашим же данным
Проверку делает человек с доступом к выгрузкам из обеих систем, подрядчик для неё не нужен и даже мешает. Задача не в том, чтобы найти причину, а в том, чтобы получить ответ на единственный вопрос: теряет ваш обмен данные прямо сейчас или нет.
- 1Запрос 1. Сверка счётчиков за одни сутки — 10 минут
Посчитайте, сколько записей создано в системе-источнике за вчерашний день, и сколько записей с вчерашней датой есть в системе-приёмнике. Числа должны совпасть. Расхождение даже в одну запись — это не погрешность, а доказательство: обмен не гарантирует доставку. При потоке 80 заявок в сутки потеря 1 % — это почти заявка в день и около 2 560 ₽ маржи.
- 2Запрос 2. Двадцать последних заявок по сквозному номеру — 10 минут
Возьмите двадцать последних записей источника и найдите каждую в приёмнике по внешнему идентификатору. Если искать приходится по телефону и по сумме, потому что общего номера нет, — вы уже нашли главную проблему: обмен без сквозного идентификатора нельзя проверить в принципе, и разбор любого спора в нём занимает часы вместо минут.
- 3Запрос 3. Группировка по телефону и сумме за месяц — 10 минут
Сгруппируйте записи приёмника за последний месяц по паре «телефон плюс сумма» и посмотрите, сколько групп содержит больше одной записи. Каждая такая группа — след повторной отправки, прошедшей без идемпотентного ключа. В модельной компании таких групп 22 в месяц, и каждую кто-то разбирает руками по 10–15 минут.
Проверка «сервис отвечает» не видит четыре сбоя из пяти. Просроченный токен, зависший обработчик, сломанный фильтр дат и изменившийся формат полей дают зелёный индикатор при нулевом или неполном обмене. Единственные две вещи, которые ловят эти случаи, — суточная сверка счётчиков и сквозной тестовый прогон одной записи по всему маршруту. Подробнее о том, какие сигналы деградации обмена видны заранее, мы писали отдельно.
Очередь с повторами и оповещение, которое читают в пятницу вечером
Промежуточный склад между двумя системами. Отправитель кладёт сообщение в очередь и считает свою работу выполненной; очередь сама пытается доставить его получателю и, если получатель не ответил, повторяет попытку через нарастающие промежутки времени. Заявка перестаёт зависеть от того, был ли получатель доступен именно в ту секунду, когда её отправляли. Без очереди обмен нельзя называть рабочим: он работает, только пока обе системы отвечают одновременно.
Про устройство самой очереди, про лестницу пауз и про то, какие операции нельзя повторять автоматически, мы написали отдельный технический разбор. Здесь важнее вторая половина обвязки, которую забывают чаще самой очереди: оповещение. Очередь без оповещения просто складывает необработанное в тихом месте, и через неделю его там столько, что разбор становится отдельным проектом.
Оповещение о сбое приходит в пятницу в 22:00 — это не гипотеза, а статистика: смежные системы чаще всего обновляют в конце недели. Поэтому у сообщения есть жёсткие требования к содержанию, и все они про то, чтобы человек, читающий его с телефона, мог принять решение за минуту.
- Что именно не прошло: тип документа и сквозной номер, а не «ошибка в интеграции». По номеру запись находится в обеих системах за секунды.
- Сколько уже накопилось. Одно неотправленное сообщение и сорок — это разные ситуации и разная реакция.
- Что будет, если ничего не делать до понедельника. Ответ «данные лежат в очереди и уйдут сами, когда получатель поднимется» закрывает вопрос; ответ «данные потеряны» требует действий сейчас.
- Что сделать прямо сейчас: одна конкретная кнопка или команда повтора, а не предложение «обратиться к разработчику».
- Кому звонить, если не помогло. Имя и телефон, а не адрес общей почты поддержки.
- Получатель — живой человек с правами, а не общий чат. Оповещение, которое приходит всем, не приходит никому: каждый считает, что отреагирует кто-то другой.
Вторая обязательная часть — ежесуточная сверка количества документов на обеих сторонах, отправляемая письмом каждое утро, в том числе когда всё в порядке. Письмо «вчера создано 78, доставлено 78» читается за две секунды и приучает глаз к норме; письмо, которое приходит только при аварии, через месяц перестают замечать вместе с самой аварией.
Сколько стоит дошить надёжность к готовому обмену
Модельная компания: оптовая торговля, 2 400 заявок в месяц, около 80 в сутки, маржа средней заявки 3 200 ₽. Обмен «форма сайта — CRM — учётная система» работает второй год, написан в один проход. Получатель бывает недоступен примерно 40 минут четыре раза в месяц: обновления, перезагрузки, пиковая нагрузка.
Сравнение, ради которого всё это считалось: та же самая обвязка, заложенная в момент разработки обмена, стоит 16 часов и 48 000 ₽ — эту смету мы разбирали в статье про обработку ошибок в сценариях. Разница в 60 000 ₽ уходит на две вещи, которых при разработке не бывает: на разбор чужого кода, который никто не документировал, и на приведение в порядок того, что уже накопилось, — дублей, зависших записей и расхождений между системами.
Двухосевой график за 8 месяцев. Синяя линия — накопленные потери от дырявого обмена, растёт на 40 460 ₽ в месяц. Серая горизонтальная штриховая линия — разовое вложение 108 000 ₽ на дошивку обвязки. Точка пересечения между вторым и третьим месяцем подписана «окупаемость» и выделена. Оси: месяцы и рубли. Под графиком легенда с разбивкой месячных потерь: 28 800 ₽ потерянная маржа, 3 960 ₽ разбор дублей, 7 700 ₽ ручная сверка.
Отдельная строка, которую в такой смете почти всегда забывают, — журнал обмена со сквозным номером. Она выглядит необязательной, пока не случается первый спор «мы отправили — вы не получали»: без журнала он не решается вообще, а с журналом закрывается за десять минут. Мы разбирали устройство журнала обмена и его цену отдельно; в этой смете он стоит 18 000 ₽ из 108 000 ₽ и оправдывает себя первым же разбором.
Сравнение в две колонки: «Заложено при разработке» и «Дошито через год работы». Строки сравнения: часов инженера (16 — 36), стоимость (48 000 ₽ — 108 000 ₽), разбор чужого кода (не нужен — 6 часов), накопленные дубли (их нет — 8 часов на склейку), простой на переключение (нет — есть). Внизу подпись: «Разница 60 000 ₽ — это цена одной вычеркнутой строки сметы». Чертёжный стиль, подписи по-русски.
Когда обвязка не нужна
Надёжность обмена стоит денег и не всегда их стоит. Есть четыре ситуации, в которых мы сами советуем ограничиться суточной сверкой за 12 000 ₽ и не покупать остальное.
- Меньше 100 записей в месяц. Обвязка стоит одинаково при 100 и при 2 400 записях, а потери при первом объёме — три-четыре заявки в год. Тут дешевле раз в день сверять счётчики глазами.
- Обмен идёт в одну сторону и не влияет на деньги: выгрузка каталога на витрину, обновление остатков раз в сутки. Потерянная передача просто повторится в следующем цикле.
- Между системами стоит человек. Если заявка в любом случае проходит через менеджера, который её глазами открывает, потери он заметит сам — и обвязка дублирует его работу.
- Обмен доживает последние месяцы: систему меняют, идёт переезд на другую платформу. Вкладывать 108 000 ₽ в контур, который выключат через квартал, смысла нет — здесь работает ручная сверка и терпение.
И одна оговорка, которая важнее всех четырёх пунктов. Если после трёх запросов из этой статьи расхождение счётчиков оказалось нулевым, а дублей нет — это ещё не значит, что обвязка есть. Это значит, что за проверенный период получатель ни разу не был недоступен. Проверку стоит повторить в конце месяца и в день, когда смежную систему обновляют: именно тогда и выясняется, что обмен держался на везении. Вторая по частоте причина расхождений — не сбои, а разные справочники в двух системах, и лечится она совсем иначе.
