Панель здоровья каналов: когда вы заметите, что WhatsApp отвалился?

Вторник, 9:40 утра. В службе поддержки интернет-магазина работают два оператора, и первый час обычно самый плотный: с девяти до десяти в WhatsApp приходит около тридцати сообщений — вопросы о доставке, возвраты, обмен размера. В то утро к одиннадцати пришло только четыре. Никто не насторожился: «спокойный день», и всё. Днём клиент написал в Instagram: «Я вам со вчерашнего дня пишу в WhatsApp, никто не отвечает». Выяснилось, что соединение оборвалось накануне в 18:20, и с этого момента ни одно сообщение не попало во входящие. На экране не было ни одной ошибки. Была только пустота, а пустота никого не будит.

В этой статье мы по порядку разбираем, как сделать обрыв канала заметным: что именно ломается, когда канал «не работает», почему сбой часами остаётся незамеченным, какие признаки указывают на проблему соединения, что проверяет и чего не проверяет мониторинг здоровья, на какой вопрос отвечают логи вебхуков, как лимит скорости незаметно сужает поток, где заканчивается автоматическое переподключение, по какому порогу настраивать оповещение для каждого канала, в каком порядке действовать команде во время сбоя и как разобрать накопившуюся очередь после восстановления.

Что именно ломается, когда канал «не работает»?

Фраза «WhatsApp не работает» складывает в одну кучу как минимум четыре разные неисправности, и именно поэтому она затягивает ремонт. Первая — падение авторизации: срок действия токена истёк или доступ отозван, система не может обратиться к платформе. Вторая — обрыв вебхука: платформа продолжает отправлять вам сообщения, но ваш адрес перестал подтверждать приём, и сообщения не доходят. Третья — лимит скорости: соединение живо, а отправка отклоняется. Четвёртая — ограничение на уровне аккаунта: упал рейтинг качества, отклонены шаблоны или номер временно ограничен.

Снаружи все четыре выглядят одинаково, а чинятся в четырёх разных местах. Токен восстанавливается переподключением, вебхук — на вашей стороне, лимит скорости — перепланированием рассылки, ограничение аккаунта решается только через саму платформу. Если вы работаете с корпоративной линией, читать таблицу неисправностей без понимания того, как эта линия подключена, почти бесполезно: стоит заранее разобраться, что такое WhatsApp Business API и какие обязательства он накладывает.

Есть и пятый класс, о котором забывают чаще всего, — личная линия, подключённая по QR-коду. Она живёт на конкретном телефоне. Разрядился аккумулятор, включился авиарежим, кто-то вышел из приложения — сессия обрывается. Технически ничего не сломалось. Просто никто не смотрел.

Почему сбой часами остаётся незамеченным?

Потому что его признак — не ошибка, а отсутствие. Большинство программных сбоев заявляют о себе сами: красное предупреждение, неудачный запрос, растущая очередь. Обрыв канала действует наоборот — он делает экран тише. Тишина не запускает у команды никакого рефлекса. Скорее наоборот, она успокаивает.

Вторая причина в том, что входящий поток естественно колеблется. Во входящие, куда в четверг утром падает тридцать сообщений, в пятницу днём может прийти восемь, и это нормально. Команда привыкла к таким качелям и по инерции списывает провал на сезонность. Если нормальный ритм канала нигде не зафиксирован, вы не заметите и того, что он нарушился. Компании, которые заранее решили, какой канал сколько весит на каком рынке, замечают отклонение быстрее, потому что знают ожидаемое распределение.

Третья причина — пересменка. Канал, замолчавший вечером, для утреннего оператора просто тихий: его точка отсчёта — сегодняшнее утро, а не вчерашний вечер. Обрывы чаще всего начинаются вне рабочего времени, и именно их труднее всего поймать.

Какие признаки указывают на проблему соединения?

Признаков пять, и ни один из них сам по себе не доказательство — они полезны только вместе. Первый — падение объёма относительно собственной истории канала, а не относительно общего числа входящих. Второй — односторонний поток: исходящие уходят, входящих нет. Это классическая подпись оборванного вебхука, потому что отправка и приём идут разными путями и один может работать без другого.

Третий — застрявший статус доставки. Если сообщения остаются в состоянии «отправлено» и не переходят в «доставлено», проблема на той стороне. Четвёртый и самый сильный — миграция канала. Клиент, не получив ответа, не исчезает, а стучится в другую дверь. Письмо или сообщение в соцсети, начинающееся со слов «я писал вам в WhatsApp, никто не ответил», — это по сути сообщение об аварии. На рынках СНГ такая миграция часто превращается во входящее сообщение в Telegram, где его тоже замечают случайно.

Пятый — молчание автоматики. Если настроен автоответ вне рабочих часов, каждое ночное сообщение порождает ответ. Ночь без единого автоответа означает ночь без единого входящего, и это более резкий сигнал, чем падение объёма, потому что он различает «мало» и «ноль».

Что проверяет мониторинг здоровья и чего он не видит?

Панель здоровья каналов в едином входящем регулярно проверяет три вещи: живо ли соединение, отвечает ли адрес вебхука и сколько времени прошло с последней активности в канале. Рядом на том же экране — отслеживание лимита скорости и логи вебхуков, то есть чтобы определить класс неисправности, не нужно открывать три разных инструмента. Её задача не в том, чтобы предотвратить сбой, а в том, чтобы сделать его видимым; различие важное, потому что никакая панель не остановит аварию на стороне платформы.

Не менее важно понимать, чего она не показывает. Живое соединение не означает, что сообщение дошло до клиента, — это видно по статусу доставки. Открытый канал не означает, что ваш текст приняли: отклонение шаблона — отдельная история. Иначе говоря, панель здоровья сообщает, не забита ли труба, но ничего не говорит о качестве воды в ней.

Больше всего пользы панель приносит в момент, когда на неё никто не смотрит. Поэтому её нужно настраивать не как вкладку, а как источник уведомлений. Экран, который кто-то должен открывать в течение дня, по определению не поймает обрыв, случившийся в два часа ночи.

На какой вопрос отвечают логи вебхуков?

Ровно на один, и он закрывает спор: платформа отправила и получили ли мы? У этого вопроса три возможных ответа, и каждый касается своей команды. Если платформа ничего не отправляла — проблема на стороне аккаунта: права, ограничение или неверная привязка номера. Если отправила, а ваш адрес не подтвердил приём — проблема в вашей инфраструктуре. Если приняли, но диалог не открылся — проблема в обработке.

Без логов разделить эти три случая нечем, и команды, которые не умеют их разделять, часами ищут не в том слое. С логами разговор перестаёт быть спором «у вас или у нас» и опирается на запись с отметками времени. Только логи дают и точное время начала сбоя — единственный вход, без которого нельзя посчитать, сколько клиентов пострадало.

Как лимит скорости незаметно сужает поток?

Лимит скорости отличается от обрыва тем, что канал жив. Соединение выглядит здоровым, панель зелёная, а часть сообщений всё равно не уходит. Самая частая причина — массовая рассылка и личные ответы расходуют одну и ту же квоту. Если кампания, стартовавшая в одиннадцать, съедает большую часть лимита, ответы, которые операторы пишут днём, встают в очередь за ней. Команда описывает это как «система тормозит»; система не тормозит, она стоит в очереди. Планируя массовую рассылку в WhatsApp законными методами, заложите общую квоту в расчёт — это самый простой способ не заблокировать собственную поддержку в день кампании.

Второй источник сужения — шаблоны. Отклонённый или приостановленный шаблон молча останавливает все привязанные к нему автоматические отправки. В сценарии уведомлений о заказе это может тянуться днями: клиент не говорит «мне не пришло уведомление», он просто звонит. Понимание того, как написать шаблон, который не отклонят, снижает число таких инцидентов в источнике.

Где заканчивается автоматическое переподключение?

Автоматическое переподключение закрывает большую часть кратковременных сбоев ещё до того, как их увидит человек: короткие обрывы сети, несколько минут нестабильности на стороне платформы, задержки обновления сессии. Таких случаев много, и без автоматики команду дёргали бы по несколько раз в день впустую. Инфляция оповещений — причина номер один того, что настоящие оповещения перестают воспринимать всерьёз.

Класс, с которым автоматика не справляется, очерчен чётко и требует человека: отозванный доступ, ограничение на уровне аккаунта, упавшая QR-сессия, изменившийся адрес вебхука. Здесь повторные попытки могут идти бесконечно, и ничего не изменится. Поэтому правило простое: задайте предел числа попыток и времени, а при его превышении система должна прекратить попытки и позвать человека. Состояние «всё ещё пробую» — это не решённая проблема.

По какому порогу настраивать оповещение для каждого канала?

Порог стоит привязывать не к объёму сообщений, а к длительности тишины. Порог по объёму даёт ложные срабатывания в дни кампаний и на праздниках, а окно тишины настраивается под собственный ритм каждого канала. Оповещения по сохранённым представлениям делают это напрямую: вы сохраняете привычную комбинацию фильтров как представление, задаёте порог и получаете уведомление при его превышении. Поскольку оповещение работает по условиям самого представления, правило вида «сообщи, если диалогов без ответа в WhatsApp стало больше пяти» настраивается отдельно по каналам, а не по всему ящику.

Канал	Обычный ритм (пример)	Порог тишины	Куда смотреть первым делом
WhatsApp Business API	От десяти до тридцати сообщений в рабочий час	Девяносто минут без входящих	Лог вебхука и статус доставки
Личная линия WhatsApp (QR)	Неравномерно в течение дня, но не ноль	Три часа без входящих	Состояние сессии и привязанного телефона
Instagram и Messenger	Вне кампаний низкий и неровный поток	Полный рабочий день без входящих	Авторизация страницы
Электронная почта	Пик утром, ровный поток днём	Четыре часа без входящих	Подключение ящика и папка со спамом
SMS	Движение только при ответе клиента	Доля ошибок отправки вдвое выше обычной	Отчёт оператора и очередь отправки

Значения в таблице приведены как пример. Выведите собственный ритм из двухнедельной истории и подтяните пороги под него. Слишком узкое окно вреднее слишком широкого: команда, которая часто получает ложные сигналы, со временем перестанет реагировать и на настоящий.

Строка с SMS живёт по другой логике: там вы не ждёте входящих, вы измеряете успешность отправки. То же различие касается электронной почты, и ошибки у этих каналов ведут себя по-разному, поэтому решить заранее, что уместнее в каком случае — SMS или письмо, значит сразу сократить число ложных срабатываний.

В каком порядке действовать команде во время сбоя?

Большая часть времени после срабатывания оповещения уходит на выяснение, кто что делает. Поэтому последовательность нужно записать заранее, привязав каждый шаг к одному вопросу. Пяти шагов ниже хватает большинству команд: первые три технические, последние два обращены к клиенту.

Шаг	Вопрос	Если ответ «нет»
1	Соединение живо?	Запустите переподключение вручную, обновите доступ
2	Платформа отправляет сообщения?	Проверьте состояние аккаунта и ограничения на платформе
3	Мы подтверждаем приём?	Проверьте адрес вебхука и ответ вашего сервера
4	У клиента открыта другая дверь?	Объявите резервный канал и обновите автоответ
5	Затронутые диалоги собраны в список?	Отметьте окно сбоя тегом и назначьте ответственного

Четвёртый шаг пропускают чаще всего. Оставить клиенту открытую дверь, пока канал лежит, — самый прямой способ снизить цену сбоя. Этой дверью может быть чат на сайте, короткое информационное сообщение или линия Viber, которая сильна на рынках СНГ; важно, чтобы альтернатива была настроена и проверена заранее. Поднимать новый канал во время аварии — значит удвоить аварию.

Если у вас есть мобильное приложение, появляется ещё один путь: сообщение внутри приложения или push доносит информацию о сбое, вообще не затрагивая мессенджер. Отношение к мобильному как к самостоятельному каналу окупается именно в такие моменты, потому что он зависит от другого поставщика и вряд ли откажет одновременно.

Пятый шаг очерчивает границы инцидента. Отметив теги на всех диалогах внутри окна сбоя, вы получаете и список для обзвона, и защиту метрики времени ответа. Иначе одна плохая ночь сделает месячное среднее бессмысленным.

Как разобрать очередь после восстановления канала?

Когда соединение возвращается, сообщения падают одной волной, и это создаёт вторую проблему: сотни диалогов открываются одновременно, все опоздали одинаково, и потому ни один не выглядит срочным. Работает только один подход — сортировать не по задержке, а по теме. Сначала заказы и оплата, потом общие вопросы. Если настроены правила распределения и цели SLA, для диалогов с тегом сбоя можно задать отдельный целевой срок и распределить нагрузку под него.

Второй вопрос — как писать запоздалый ответ. «Извините за задержку в связи с высокой нагрузкой» не говорит клиенту ничего; куда лучше воспринимается прямая формулировка: был технический сбой, ваше сообщение не потерялось. Поскольку история клиента лежит рядом с диалогом, запоздалый ответ можно начать с контекста, а не с извинения, и это работает сильнее. Если потом захотите последить за аккаунтами, которые пострадали сильнее всех, посмотрите, как оценка здоровья клиента отмечает аккаунт в зоне риска: последствия сбоя видны в этой оценке ещё несколько недель.

Третий шаг относится к продажам, и о нём обычно забывают. Часть тех, кто писал во время сбоя, обращалась не в поддержку — они были готовы покупать. Эти диалоги нужно просмотреть отдельно, потому что вопрос в поддержку подождёт, а горячий запрос нет. Здесь работает та же логика, что и в оценке здоровья сделки, которая показывает, какая сделка застряла: замолчавшая возможность — это ещё не проигранная возможность.

Чтобы превратить всё это в рабочую рутину вместо аврала, заведите бесплатный аккаунт Rocketly и для начала соберите каналы в один ящик.

Частые вопросы

За сколько минут разумно замечать обрыв канала?

В рабочее время большинству команд по силам уложиться в тридцать — девяносто минут; вне рабочего времени цель другая: тот, кто первым откроет ящик, должен сразу видеть состояние канала. Важна не сама цифра, а то, что она записана по каждому каналу и связана с оповещением.

Если переподключение автоматическое, нужны ли оповещения?

Нужны. Автоматика закрывает временные сбои, но не постоянные. Привяжите оповещение не к самому обрыву, а к состоянию «превышен предел попыток», и вы поймаете настоящую аварию, не утонув в уведомлениях.

Почему личная линия по QR обрывается чаще?

Потому что она зависит от устройства, которое вы не контролируете. Выключенный телефон, выход из приложения или долгое отсутствие сети завершают сессию. Перенос критичных сценариев с личной линии на корпоративный номер снижает этот риск.

Дойдут ли сообщения, отправленные во время сбоя?

Зависит от канала. Одни платформы повторяют доставку в течение определённого окна, и после восстановления всё приходит разом; на других после закрытия окна сообщение теряется. Поэтому сокращать время сбоя надёжнее, чем рассчитывать на дозагрузку.