Главное свойство сломанного обмена — он ломается беззвучно. Сайт работает, CRM открывается, 1С проводит документы: у каждой системы по отдельности всё в порядке, и ни одна не считает своей задачей сообщить, что данные между ними перестали ходить. Поэтому первым о поломке узнаёт клиент, а не вы, и в среднем это происходит через полтора рабочих дня.
Вторая особенность важнее первой. Интеграции почти никогда не падают разом — они деградируют. Сначала растёт доля отказов, потом копится очередь, потом обработчик начинает отвечать медленнее, и только через несколько дней обмен останавливается совсем. Мониторинг нужен не для того, чтобы узнать о падении быстрее, а для того, чтобы увидеть деградацию, пока падения ещё нет.
Ниже — восемь сигналов с конкретными порогами, объяснение, почему проверка доступности сервиса ничего не гарантирует, схема оповещения, которая доходит до живого человека, и расчёт на модельном потоке 1 100 заказов в месяц. Главный вывод этого расчёта неудобен для подрядчика: дешёвый набор из двух датчиков за 27 000 ₽ забирает почти весь эффект дорогого контура за 90 000 ₽ плюс 13 000 ₽ в месяц.
Восемь сигналов и их пороги
Каждый сигнал ловит то, чего не ловят остальные семь. Пороги в таблице даны для обмена с интервалом 15 минут и потоком около 1 100 операций в месяц — на других объёмах числа надо пересчитывать, но логика порога остаётся той же: тревога поднимается не при первом отклонении, а при устойчивом.
| Сигнал | Порог тревоги | О чём говорит | Что делать первым |
|---|---|---|---|
| Возраст последнего успешного обмена | Больше 45 минут при интервале 15 минут — три пропущенных запуска | Процесс умер, сервер недоступен, кончилось место на диске | Проверить, жив ли процесс обмена, и перезапустить |
| Длина очереди | Больше 100 сообщений или непрерывный рост 30 минут | Получатель лежит или не справляется со скоростью | Проверить доступность получателя, не выпускать очередь разом |
| Доля отказов за час | Больше 5 % попыток | Деградация на той стороне, истёкший ключ, изменившийся формат | Открыть журнал и прочитать текст ответа получателя |
| Время ответа получателя | 95-й процентиль выше 3 секунд при обычных 0,4 секунды | Приёмник перегружен, скоро начнутся таймауты | Снизить скорость выпуска очереди, предупредить владельца системы |
| Доля операций с повторами за сутки | Больше 3 % операций потребовали больше одной попытки | Связь нестабильна, авария приближается | Смотреть, повторы по всем направлениям или по одному |
| Размер карантина | Больше 10 сообщений или рост третьи сутки подряд | Дыра в справочнике или неописанное правило | Разобрать причины: одна повторяющаяся или разные |
| Расхождение суточных счётчиков | Любое расхождение сверх законных отмен и объединений | Тихая потеря документов при внешне работающем обмене | Найти недостающие документы по журналу и добрать |
| Использование лимита чужого API | Больше 80 % суточной квоты израсходовано к 60 % суток | К вечеру упрётесь в лимит и получите отказы на нормальных заявках | Снизить частоту опроса или перейти на события |
Обратите внимание на седьмую строку. Расхождение счётчиков — единственный сигнал, который ловит ситуацию, когда обмен работает, но данные не доезжают. Все остальные семь измеряют состояние механизма, а этот — результат. Если бюджет позволяет только один датчик, брать надо именно его.
Карта связей: пять узлов в ряд — «Сайт», «Приёмник», «Очередь», «Обработчик», «1С и CRM», соединённые стрелками с подписями «новая заявка», «сообщение в буфере», «документ». К узлам подведены восемь помеченных датчиков на выносках: к «Приёмнику» — «возраст последнего успешного обмена, порог 45 минут» и «использование лимита API, порог 80 %»; к «Очереди» — «длина очереди, порог 100» и «размер карантина, порог 10»; к «Обработчику» — «доля отказов за час, порог 5 %», «время ответа, порог 3 с», «доля операций с повторами, порог 3 %»; отдельная широкая штриховая дуга от «1С и CRM» обратно к «Сайту» подписана «суточная сверка счётчиков: сайт 50 — CRM 50 — учёт 50, расхождение = тихая потеря». Чертёжный стиль, подписи по-русски.
Почему «сервис отвечает» ничего не доказывает
Самая распространённая имитация мониторинга — проверка доступности: раз в минуту система стучится по адресу сервиса и убеждается, что тот отвечает. Это проверяет ровно одно — что веб-сервер поднят. Обмен при этом может не идти вообще, и индикатор останется зелёным.
| Что случилось на самом деле | Что показывает проверка доступности | Какой сигнал ловит |
|---|---|---|
| Истёк ключ доступа: сервис отвечает, но отказом авторизации на каждый запрос | Зелёный: сервис отвечает | Доля отказов за час |
| Обработчик завис на одном сообщении: процесс жив, но ничего не обрабатывает | Зелёный: процесс запущен | Длина очереди и возраст последнего успешного обмена |
| Сломался фильтр периода: обмен исправно ходит и забирает пустоту | Зелёный: обмены проходят успешно | Только суточная сверка счётчиков |
| Изменился формат ответа после обновления чужого сервиса | Зелёный: ответ приходит | Доля отказов и размер карантина |
| Кончилось место на диске под очередь | Зелёный, пока не упадёт весь сервер | Возраст последнего успешного обмена |
В трёх строках из пяти проверка доступности показывает норму при полностью неработающем обмене. Требуйте от подрядчика ответ на конкретный вопрос: «какой именно датчик заметит, что обмен идёт, но документы не создаются?» Правильный ответ — суточная сверка количеств. Ответ «мы мониторим доступность сервисов» означает, что этот класс поломок вы будете обнаруживать через клиента.
Сквозной тестовый сценарий: проверка всего маршрута
Датчики измеряют состояние узлов. Сквозной тест измеряет результат: раз в 30 минут система сама создаёт тестовую заявку с признаком «тест», прогоняет её по всему маршруту и проверяет, появился ли документ у получателя. Не появился за отведённое время — тревога, независимо от того, что показывают остальные датчики.
Стоит такой сценарий 28 000 ₽ и требует трёх решений, которые надо принять до разработки, иначе он превратится в источник мусора в вашем учёте.
- Тестовые записи помечаются и удаляются автоматически. Иначе через год у вас 17 000 тестовых контрагентов, а бухгалтерия ищет их руками перед закрытием года.
- Тестовые записи исключаются из отчётности и из счётчиков сверки. Иначе седьмой сигнал начнёт срабатывать на собственный тест, порог поднимут, и настоящее расхождение потеряется в шуме.
- Тест не должен трогать деньги, остатки и клиента. Тестовая заявка не резервирует товар, не создаёт платёж и не порождает SMS. Это те же четыре операции, которые нельзя повторять автоматически, — их список разобран в статье про очереди и повторные попытки.
Сравнение в две горизонтальные полосы над одним и тем же маршрутом из пяти узлов: «Сайт», «Приёмник», «Очередь», «Обработчик», «1С:УТ». Верхняя полоса «Проверка доступности»: короткая стрелка касается только узла «Приёмник», рядом зелёная галочка и подпись «сервис отвечает, 0 ₽». Ниже перечень пропущенного: «истёкший ключ», «зависший обработчик», «сломанный фильтр дат» — все с зелёными галочками и пометкой «не заметит». Нижняя полоса «Сквозной тестовый сценарий, 28 000 ₽»: стрелка проходит все пять узлов и упирается в отметку «документ создан?» у 1С:УТ, рядом подписи «раз в 30 минут», «запись помечена как тест», «удаляется автоматически», «не трогает остатки и деньги». Чертёжный стиль, подписи по-русски.
Кому уходит оповещение и что этот человек обязан сделать
Датчик без адресата бесполезен. Самая частая ошибка — отправлять оповещения письмом на общий ящик вроде «ит» или «поддержка». Адресат «все» означает адресат «никто»: письмо тонет между рассылками, а через две недели поток однотипных сообщений становится фоном, который перестают открывать вовсе.
- 1Ступень 1, сразу
Сообщение в мессенджер конкретному человеку с именем — вашему сотруднику или дежурному подрядчика. В сообщении обязательно: какой датчик, какое значение, какой порог, номер заявки и текст ответа получателя. Без этих полей адресат идёт выяснять, что произошло, и теряет первые двадцать минут.
- 2Ступень 2, через 30 минут без реакции
То же сообщение уходит второму адресату — руководителю или второму инженеру. Без второй ступени первая превращается в лотерею: человек может быть в дороге, на встрече или в отпуске, о котором никто не предупредил систему.
- 3Ступень 3, через 2 часа
Звонок. Он нужен ровно для одного класса ситуаций: обмен встал с утра, никто не отреагировал, и к вечеру набежит объём, который придётся восстанавливать руками несколько часов.
- 4Гигиена порогов
Если сигнал срабатывает чаще раза в неделю и не требует действий — чините порог или чините систему. Норма для здорового контура — не больше четырёх оповещений в месяц, и почти все требуют действия. Контур, который шлёт по десять сообщений в день, эквивалентен отсутствию мониторинга, только за деньги.
Схема из трёх последовательных блоков, соединённых стрелками с подписями времени. Блок 1 «0 минут»: значок мессенджера, подпись «дежурный инженер, лично», под ним карточка сообщения с полями «датчик: доля отказов», «значение: 11 %», «порог: 5 %», «заявка R-20418», «ответ: 401, ключ доступа истёк». Блок 2 «через 30 минут без реакции»: тот же значок с подписью «руководитель». Блок 3 «через 2 часа»: значок телефона с подписью «звонок». Сбоку перечёркнутый блок «письмо на общий ящик» с подписью «адресат «все» = адресат «никто»». Внизу строка: «Норма здорового контура — не больше 4 оповещений в месяц». Чертёжный стиль, подписи по-русски.
Сколько стоит один незамеченный день
Модельная компания: 1 100 заказов в месяц, 22 рабочих дня — то есть 50 заказов в рабочий день или 6,25 заказа в рабочий час. Средний чек 8 200 ₽, маржа 22 %, то есть 1 804 ₽ с заказа. Обмен «сайт → CRM → 1С:УТ» встал во вторник утром, заметили в среду днём по звонку клиента: простой 1,5 рабочих дня, или 12 рабочих часов.
Теперь тот же простой при работающем мониторинге. Мониторинг не предотвращает поломку — он сокращает время до обнаружения. С сигналом присутствия и оповещением в мессенджер сотруднику простой длится час: не доехало 6 заказов, отказов нет, восстановление занимает 45 минут, разбор причины у подрядчика остаётся прежним — 3 часа по 3 000 ₽, потому что чинить всё равно надо. Итого 825 + 9 000 = 9 825 ₽ вместо 28 620 ₽. Экономия на одном простое — 18 795 ₽.
С полным контуром и круглосуточным дежурством подрядчика простой сокращается до 40 минут: не доехало 4 заказа, восстановление 30 минут, итого 9 550 ₽. Экономия — 19 070 ₽. Разница между дорогим и дешёвым вариантом составляет 275 ₽ на один простой, а доплата за дежурство — 13 000 ₽ в месяц.
Сверка счётчиков: дешёвый мониторинг, который забирает почти весь эффект
Суточная сверка — это три числа в письме в 9 утра: сколько заказов создано на сайте вчера, сколько сделок появилось в CRM, сколько документов в учёте. Стоит 15 000 ₽, ставится за несколько дней и закрывает седьмой сигнал — тот самый, который не ловит ничто другое. Вместе с сигналом присутствия за 12 000 ₽ получается набор за 27 000 ₽ без доплаты к поддержке.
Схема «пишем только при проблемах» не работает: молчание системы неотличимо от сломанного мониторинга. Ежедневное письмо со строкой «сайт 50, CRM 50, учёт 50, расхождений нет» — это и есть доказательство работы обмена. Его отсутствие два дня подряд — сигнал сам по себе.
| Набор | Разово | Доплата к поддержке | Сигналов из восьми | Простой сокращается до |
|---|---|---|---|---|
| Ничего | 0 ₽ | 0 ₽ | 0 | 1,5 рабочих дня |
| Суточная сверка счётчиков | 15 000 ₽ | 0 ₽ | 1 | 1 рабочий день |
| Сверка и сигнал присутствия | 27 000 ₽ | 0 ₽ | 2 | 1 час в рабочее время |
| Три датчика: сверка, присутствие, счётчик отказов | 62 000 ₽ | 0 ₽ | 3 | 1 час в рабочее время |
| Восемь датчиков, сквозной тест и дежурство | 90 000 ₽ | 13 000 ₽/мес | 8 | 40 минут круглосуточно |
Свести это в решение помогает простая арифметика. При типичной для средней компании частоте в 3–4 незамеченных простоя в год дешёвый набор за 27 000 ₽ приносит 4 × 18 795 = 75 180 ₽ в год и окупается вторым же простоем. Полный контур приносит 76 280 ₽ в год — на 1 100 ₽ больше — при доплате 13 000 × 12 = 156 000 ₽ в год за дежурство. В этой модели дежурство не окупается и близко. Порядок цен по остальным строкам надёжности и то, как они складываются в общую смету, разобраны в материале о стоимости надёжной интеграции.
Диаграмма из трёх сгруппированных столбцов по одному незамеченному простою. Столбец 1 «Без мониторинга»: потери 28 620 ₽, разбит на сегменты «потерянная маржа 9 020», «восстановление 6 600», «разбор у подрядчика 9 000», «компенсации 4 000». Столбец 2 «Сверка и сигнал присутствия, 27 000 ₽ разово»: потери 9 825 ₽, над столбцом подпись «экономия 18 795 ₽». Столбец 3 «Полный контур, 90 000 ₽ разово и 13 000 ₽/мес»: потери 9 550 ₽, над столбцом подпись «экономия 19 070 ₽». Между вторым и третьим столбцом узкая скобка с подписью «разница 275 ₽ за простой». Внизу строка: «При 4 простоях в год: 75 180 ₽ против 76 280 ₽; доплата за дежурство — 156 000 ₽ в год». Чертёжный стиль, подписи по-русски.
Что писать в договор поддержки
Мониторинг существует не как программа, а как договорённость: кто смотрит, в какие часы, за какое время отвечает и что показывает по итогам месяца. Шесть пунктов ниже формулируются одним абзацем и снимают почти все будущие споры.
- 1Время реакции, а не время починки. «Через 4 часа в рабочие дни с 9:00 до 18:00 по московскому времени вы знаете, что происходит и когда будет решение» — это выполнимое обязательство. «Починим за 4 часа» не выполнимо ни для кого, потому что причина может быть на стороне чужого сервиса.
- 2Кто дежурит и в какие часы. Конкретная роль, а не «команда». Отдельно оговариваются выходные и ночь: если ваш поток круглосуточный, а дежурство рабочее, ночной сбой будет обнаружен утром — и это нормально, если вы знаете об этом заранее.
- 3Список сигналов и порогов приложением к договору. Через год без этого приложения начнётся спор о том, что считать аварией. Пороги должны быть числами, а не словами «критический рост».
- 4Доступ заказчика к журналу обменов через веб-интерфейс. Без него ваш сотрудник не сможет ни проверить сигнал, ни ответить клиенту; состав журнала и глубина хранения разобраны в статье про логи обменов.
- 5Ежемесячный отчёт. Сколько сигналов сработало, сколько расхождений нашла сверка, что с ними сделано. Это единственное доказательство, что вы платите за работающий контур, а не за строчку в счёте.
- 6Границы ответственности. Техническая доставка — зона подрядчика. Корректность справочников и содержание заявок — зона заказчика. Как мы это разделяем, описано на странице гарантий.
Когда мониторинг не нужен
Полный контур — не признак зрелости, а инструмент под конкретный профиль риска. Четыре ситуации, в которых мы отговариваем от него сами.
- Меньше 100 операций в месяц. Простой в полтора дня стоит здесь 2–3 заказа, то есть около 5 000 ₽. Ни один набор датчиков не окупится. Работающая замена — раз в неделю сравнить два числа руками: сколько заявок было и сколько документов появилось.
- Обмен идёт только справочными данными. Остатки, цены, курсы: каждое обновление перезаписывает предыдущее целиком, и пропуск одного цикла ничего не значит. Достаточно одного датчика — возраста последнего успешного обмена.
- Некому реагировать. Если оповещение уходит человеку, который не может ни перезапустить обмен, ни позвонить подрядчику, контур бесполезен вне зависимости от цены. Сначала назначается ответственный с полномочиями, потом покупаются датчики, а не наоборот.
- Обмен ещё не построен как надёжный. Мониторинг показывает состояние очереди, число повторов и размер карантина. Если очереди и повторов нет, шесть из восьми датчиков нечего измерять, а два оставшихся будут исправно сообщать о потерях, которые вы всё равно не сможете предотвратить. Порядок правильный: сначала надёжная схема обмена, потом наблюдение за ней.
И честный ответ на вопрос, когда полное дежурство всё-таки оправдано. Три условия, при которых расчёт разворачивается в его пользу: поток круглосуточный, и ночной сбой к утру стоит уже не 28 620 ₽, а вдесятеро больше; объём такой, что рабочий час простоя — это десятки заказов; или процесс регулируемый, и расхождение данных грозит не потерей маржи, а штрафом — как в маркировке или в прослеживаемости. Если ни одно из трёх условий не выполняется, берите два датчика за 27 000 ₽ и потратьте разницу на очередь и журнал.
Мониторинг не делает обмен надёжнее. Он делает так, что о поломке узнаёте вы, а не ваш клиент.
