Мониторинг обычно ставят технический: проверка доступности каждую минуту, оповещение в чат, если сервис не ответил. Он полезен и стоит недорого, но ловит меньшую часть аварий. Ломается чаще не техника, а бизнес-смысл: сервис отвечает, ошибок в журнале нет, интеграция формально работает — и при этом вторые сутки никто не разбирает очередь, потому что обращения перестали попадать в нужную категорию.
Разница видна по тому, кто сообщает о проблеме. Технический сбой находит мониторинг, бизнесовый — клиент или менеджер, обычно с опозданием на несколько дней. Поэтому рабочий набор сигналов всегда смешанный: примерно половина отвечает на вопрос «жива ли система», вторая половина — на вопрос «делает ли она то, ради чего её ставили».
Дальше — девять сигналов, которых достаточно контуру среднего размера, пороги к ним, правила маршрутизации оповещений и разбор, что делать с шумом. Сквозной пример тот же, что в разборе первого года эксплуатации: оптовая компания на 60 человек, ассистент в клиентском канале, классификатор обращений, автозаполнение CRM и обмен с 1С:УТ, 3 000 обращений в месяц — это 100 в сутки.
Девять сигналов и кому уходит каждый
Сигнал — это не «график, на который иногда смотрят», а проверка с порогом и адресатом. Если у показателя нет порога или нет человека, которому уходит тревога, это не сигнал, а украшение дашборда. В таблице ниже — минимально достаточный набор для контура из четырёх звеньев.
| Сигнал | Тип | Порог тревоги | Кому уходит |
|---|---|---|---|
| Недоступность сервиса | технический | 3 неудачные проверки подряд, то есть 3 минуты | Дежурный инженер, немедленно |
| Доля ошибок обмена за сутки | технический | свыше 2 % операций два дня подряд | Инженер подрядчика, в рабочий чат |
| Возраст старейшего неразобранного обращения | бизнесовый | свыше 4 рабочих часов; критично — свыше 8 | Руководитель поддержки и владелец процесса |
| Доля обращений, переданных человеку | бизнесовый | рост на треть от базового за месяц | Владелец процесса, недельная сводка |
| Расход на запросы к модели за сутки | бизнесовый | свыше 150 % от среднего за 14 дней | Администратор системы, в рабочий чат |
| Время ответа, 95-й перцентиль | технический | свыше 15 секунд в течение 15 минут | Дежурный инженер |
| Аномальный объём обращений | бизнесовый | отклонение свыше 60 % от среднего для этого дня недели | Руководитель поддержки |
| Свободное место и рост журналов | технический | менее 20 % свободного места | Инженер подрядчика, в рабочий чат |
| Срок действия токена, ключа, сертификата | технический | за 14 дней до истечения, затем за 3 и за 1 | Администратор системы и инженер |
Последний сигнал выглядит мелочью, а на практике это самая обидная авария первого года: ключ доступа к внешней системе истекает в субботу, обмен встаёт, и полдня уходит на выяснение, почему «ничего не меняли, а не работает». Напоминание за две недели снимает этот класс инцидентов целиком и настраивается за полчаса.
В списке намеренно нет привычных технических показателей вроде загрузки процессора и расхода памяти. Они полезны инженеру, когда он уже разбирается с конкретной аварией, но как сигнал тревоги дают почти только ложные срабатывания: нагрузка скачет от любой фоновой задачи, а бизнес при этом не страдает. Правило отбора такое: сигнал остаётся в списке, если по нему хотя бы раз в квартал кто-то что-то делает. Всё остальное живёт в журналах и открывается по требованию.
Сравнение в две колонки. Левая «Технический мониторинг видит»: сервис не отвечает, ошибки обмена свыше 2 %, время ответа свыше 15 секунд, кончилось место, истёк ключ — подпись «5 сигналов, ставит подрядчик». Правая «Бизнес-мониторинг видит»: обращения не разбираются свыше 4 часов, эскалации выросли на треть, расход на модель свыше 150 % от среднего, объём обращений отклонился на 60 % — подпись «4 сигнала, пороги задаёте вы». Внизу общая строка: «сбой без техники: сервис жив, 35 из 100 обращений в сутки уходят в никуда». Чертёжный стиль, подписи по-русски.
Как выглядит сбой, которого не видит техника
В модельной компании поменяли названия двух категорий обращений в CRM. Классификатор продолжил работать: он исправно принимал обращения, отвечал за 3 секунды, ошибок в журнале не было. Но два правила маршрутизации перестали срабатывать, и обращения, которые раньше уходили менеджерам по закупкам, стали падать в общую папку «прочее». Доля «прочего» выросла с 6 % до 41 % за сутки и держалась там девять дней, пока один из клиентов не позвонил с вопросом, почему на его заявку никто не ответил неделю.
Ни один технический сигнал здесь не сработал бы, потому что с точки зрения техники всё было в порядке. Сработал бы бизнесовый: возраст старейшего необработанного обращения перевалил за 4 часа в первые же сутки. Это же расхождение системы с изменившимся бизнесом мы разбирали как отдельный класс поломок — мониторинг здесь работает как ранняя сигнализация, а не как средство лечения.
Линейный график за 12 дней. Ось Y — доля обращений в категории «прочее», от 0 до 50 %. Линия идёт на уровне 6 % три дня, затем скачком поднимается до 41 % и держится девять дней. Горизонтальная штриховая линия порога на 12 % с подписью «порог тревоги: вдвое от базовых 6 %». Вертикальная отметка на девятом дне после скачка: «звонок клиента» с подписью «ущерб 51 480 ₽». Отдельная отметка на второй день после скачка: «здесь сработал бы сигнал». Подписи по-русски.
Откуда брать пороги, если системе месяц
Числа из таблицы выше — ориентиры, а не константы. Настоящие пороги снимаются с вашей системы: первые две недели после стабилизации она работает штатно, и в это время фиксируются базовые значения по каждому сигналу. Дальше действует простое правило: базовое значение плюс 50 % — предупреждение в чат, вдвое выше базового — тревога дежурному.
- 1Снять базу за две недели
Записать среднее и разброс по каждому из девяти показателей отдельно для будних дней и выходных. В модельном примере база такая: эскалации 12 %, «прочее» 6 %, расход на модель 120 ₽ в сутки, время ответа 3 секунды, ошибок обмена 0,4 %.
- 2Проверить базу на здравый смысл
Если базовое значение уже плохое, порог от него закрепит проблему. Возраст неразобранного обращения в 6 часов — не база, а неисправность; для таких показателей порог берётся от требования бизнеса, а не от факта.
- 3Задать два уровня и записать в регламент
Предупреждение — в рабочий чат без побудки. Тревога — дежурному по правилам SLA. Пороги живут в одном документе с временем реакции, иначе через полгода никто не помнит, почему выбрано именно это число.
- 4Пересматривать раз в квартал
Бизнес растёт, объёмы меняются, порог по абсолютному числу обращений устаревает первым. Пересмотр занимает 30 минут и делается на том же квартальном техосмотре, что и остальная ревизия системы.
Два отдельных замечания про пороги по объёму. Первое: будни и выходные считаются раздельно, иначе субботнее падение потока вдвое каждую неделю будет выглядеть аварией. Второе: у сезонного бизнеса база живёт максимум квартал — при росте потока с 3 000 до 5 000 обращений в месяц порог «свыше 60 % от среднего» начинает срабатывать на обычном рабочем дне. Это одна из причин, по которой пороги входят в квартальную ревизию системы, а не настраиваются один раз при запуске.
Оповещение, на которое можно среагировать
Сообщение «Ошибка в системе» бесполезно: получатель не понимает ни масштаба, ни того, надо ли вставать. Полезное оповещение отвечает на пять вопросов сразу и умещается в экран телефона. Канал при этом вторичен — рабочий чат, почта или звонок, — важнее состав и то, что каждое событие приходит ровно одним сообщением, а не тремя от разных проверок.
- Что случилось, человеческим языком: «обмен с 1С:УТ не проходит», а не «exit code 1 в задаче sync_stock».
- Когда началось и сколько длится: «с 09:10, идёт 16 минут». Без длительности невозможно понять, свежее это событие или тянется с ночи.
- Сколько затронуто: «не выгружено 240 строк остатков, 18 заказов ждут». Масштаб решает, будят человека или нет.
- Куда смотреть: прямая ссылка на журнал события и на карточку системы в документации.
- Что делать первым действием: одна строка инструкции — «включить ручную выгрузку остатков по инструкции 3.2» или «ничего не делать, дежурный уже принял».
Отдельный вопрос — список получателей. Рабочее правило: у каждого сигнала ровно один ответственный получатель и один заместитель, а не «все, кого добавили в чат». Технические сигналы уходят инженеру подрядчика, бизнесовые — владельцу процесса на вашей стороне, деньги на модель и минуты — администратору системы. Руководитель в списке не для того, чтобы чинить, а для того, чтобы через два часа увидеть, что инцидент до сих пор открыт. Общий чат из двадцати человек — это гарантированное «я думал, посмотрит кто-то другой».
Нарисованный абстрактный экран сообщения в рабочем чате, разбитый на пять подписанных зон. Зона 1 «что»: «Обмен с 1С:УТ не проходит». Зона 2 «когда»: «с 09:10, идёт 16 минут». Зона 3 «масштаб»: «240 строк остатков, 18 заказов ждут». Зона 4 «куда смотреть»: строка со ссылкой на журнал события. Зона 5 «первое действие»: «включить ручную выгрузку по инструкции 3.2». Сбоку пометка «одно событие — одно сообщение» и перечёркнутый пример «Ошибка в системе». Чертёжный стиль без реального интерфейса, подписи по-русски.
Шум: почему через две недели оповещения перестают читать
Типичный контур после настройки выдаёт 40–60 сообщений в сутки, из которых действия требуют два. Через две недели чат с оповещениями сворачивают, а ещё через месяц из него выходят. Дальше система остаётся без наблюдения, но с иллюзией наблюдения — это хуже, чем не иметь мониторинга вовсе, потому что бюджет потрачен, а сбой снова находит клиент.
Считайте это проектным требованием наравне со временем реакции. Если сигналов приходит больше, лечится это не привычкой, а инженерной работой: дедупликацией, окном повторов и разделением каналов. Проверка простая — за прошедшую неделю посмотрите, по скольким оповещениям кто-то что-то сделал. Если по трём из сорока, контур настроен неправильно.
- Дедупликация. Одно событие — одно сообщение. Пятьдесят неудачных попыток обмена подряд — это один инцидент со счётчиком, а не пятьдесят тревог.
- Окно повторов. Пока инцидент открыт, напоминание приходит раз в два часа, а не при каждой новой ошибке. Закрытие инцидента подтверждается отдельным коротким сообщением.
- Разные каналы по критичности. Тревога — звонок или отдельный канал с побудкой дежурного. Предупреждение — рабочий чат. Информация — суточная сводка одним письмом утром.
- Пауза на время работ. В согласованном окне обслуживания оповещения отключаются заранее, иначе плановые работы каждый раз выглядят как авария.
- Каждое оповещение требует действия. Если по сигналу за квартал ни разу ничего не делали, его переводят в сводку или удаляют. Список сигналов должен худеть, а не только расти.
Дежурство: кто смотрит в 22:00 и что он делает
Оповещение бесполезно, если его некому получить. При этом круглосуточное дежурство у подрядчика стоит денег и окупается не всем — арифметику этого выбора мы разбирали в материале про SLA. Промежуточный вариант, который закрывает большую часть случаев: своё вечернее дежурство из трёх сотрудников по очереди, доплата 500 ₽ за ночь и 2 000 ₽ за фактический подъём. Это около 19 000 ₽ в месяц при двух подъёмах против 50 000 ₽ за тариф с вечерним покрытием у подрядчика.
Но такое дежурство работает только при трёх условиях: у дежурного есть доступы, есть инструкция на одну страницу и есть телефон инженера подрядчика для эскалации. Без них человек ночью только пересылает сообщение в общий чат, где его всё равно никто не прочитает до утра.
- 1Проверить по списку из трёх пунктов, что именно не работает: отвечает ли сервис, идёт ли обмен, копится ли очередь. Пять минут по инструкции, без разбирательства в причинах.
- 2Включить обход, если он предусмотрен: переключить приём заявок на почту, отключить сломанный сценарий бота, запустить ручную выгрузку. Чинить причину дежурный не должен и не имеет права.
- 3Уведомить владельца процесса коротким сообщением: что случилось, что включён обход, когда ждать инженера. Одно сообщение, не переписка.
- 4Записать в журнал инцидентов: время, признаки, что сделал. Утренний разбор начинается с этой записи, иначе половина деталей теряется.
Схема из блоков со стрелками слева направо. Слева столбец «проверки: 9 сигналов». Далее блок «порог: база +50 % — предупреждение, ×2 — тревога». Далее блок «дедупликация: одно событие — одно сообщение, повтор раз в 2 часа». Далее развилка на три ветки: «тревога → звонок дежурному, побудка», «предупреждение → рабочий чат», «информация → сводка одним письмом в 8:00». От ветки дежурного стрелка вниз к блоку «обход по инструкции, 4 действия» и дальше к блоку «эскалация инженеру подрядчика». Сбоку пометка «норма: 3–5 сообщений в сутки». Чертёжный стиль, подписи по-русски.
Самая частая ошибка: дежурного назначили, а доступ к серверу, к панели интеграции и к учётной записи бота у него не оформлен, потому что «безопаснее». В результате ночью он может только позвонить тому, у кого доступ есть, — и вся конструкция сводится к обычному звонку, но с оплатой дежурства. Права дежурного оформляются заранее и по минимально необходимому набору: включить обход, перезапустить задачу, отключить сценарий. Ничего сверх этого.
Мониторинг без бюджета: три вещи за один день
Если денег на полноценный контур сейчас нет, есть минимальный набор, который собирается за один рабочий день и закрывает четыре сигнала из девяти — включая два бизнесовых, самых дорогих. Он не заменяет мониторинг, но снимает класс аварий, которые иначе находят через неделю.
Сверка количеств — самая недооценённая проверка из трёх. Она не требует знания внутренностей систем: достаточно сравнить два числа за сутки. Именно она ловит тихие расхождения обмена, при которых часть документов теряется без единой ошибки в журнале — а такие расхождения дают самый долгий и самый дорогой шлейф. Задачу раскладки обращений по категориям, с которой начался разбор, решает отдельный компонент каталога — классификация обращений, а контроль сроков ответа клиентам — соседний.
Когда мониторинг усложнять не надо
Наблюдение — это тоже система, за которой надо следить, и она стоит времени. Есть случаи, когда развёрнутый контур не нужен и лучше ограничиться минимальным набором из предыдущего раздела.
- Контур из одного сценария без интеграций. Бот отвечает на вопросы по базе знаний и никуда не пишет — здесь достаточно проверки доступности и недельного отчёта по эскалациям. Девять сигналов ему не по размеру.
- Процесс терпит сутки. Если ночная выгрузка отчёта не прошла, а бизнес узнает об этом утром и переживёт, ночная побудка дежурного лишняя: хватит утреннего письма.
- Некому получать тревоги. Мониторинг без адресата бесполезен на 100 %. Пока не назначен человек с именем и правами, деньги на настройку лучше не тратить — сначала роль, потом инструмент.
- Система в первый месяц после запуска. Пороги ещё не с чего снимать, поток нестабилен, ложных тревог будет больше, чем настоящих. В стабилизацию смотрят руками и ежедневно, а автоматические пороги ставят на третьей-четвёртой неделе.
И честная граница возможностей: мониторинг не делает систему надёжнее, он сокращает время, в течение которого поломка остаётся незамеченной. В модельном примере это разница между девятью днями и одним, то есть между 51 480 ₽ и примерно 6 000 ₽ ущерба. Всё остальное — обход, починка, разбор причин и обновление правил — по-прежнему делают люди по регламенту, и без этих людей самый подробный набор сигналов остаётся набором графиков.
Хороший мониторинг измеряется не числом графиков, а числом сбоев, о которых вы узнали раньше клиента.
