Как настроить резервирование SMS-канала через двух провайдеров

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

Почему один канал — это одна точка отказа

Даже аккуратный провайдер зависит от чужих звеньев: сессий SMPP, маршрутов к операторам, биллинга, репутации отправителя. Когда одно звено проседает, вы видите одну из трёх картин.

• Сессия SMPP закрылась. Привязка (bind) уходит в нерабочее состояние, отправка (submit_sm) не проходит, ошибку видно сразу.
• Сообщения принимаются, а отчёты о доставке не приходят. Снаружи всё выглядит рабочим, при этом до людей доходит малая часть.
• Доставка просела частично: один оператор принимает сообщения, другой молчит.

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

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

Схемы отличаются тем, сколько ручной работы они требуют и насколько быстро переносят поток.

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

Как настроить переключение: пошаговый план

Порядок действий примерно одинаков и для самописной системы, и для готового шлюза.

1. Договоритесь о доступе с двумя провайдерами. Просите SMPP-подключение версии 3.4 или HTTP API. Полезно, чтобы оба умели одно и то же: своё имя отправителя, отчёты о доставке, приём входящих сообщений.
2. Согласуйте одинаковое имя отправителя у обоих. Разные подписи путают клиента, а статистика по каналам становится несопоставимой.
3. Присвойте каждому сообщению внутренний ID. Это ключ в вашей базе, который связывает попытки отправки через обоих провайдеров. Без него вы не поймёте, что уже ушло.
4. Определите, что считаете сбоем. Варианты: разрыв привязки, таймаут на отправку, доля ошибок выше порога, отсутствие отчётов о доставке за отведённое время.
5. Пропишите правило возврата. Сразу после восстановления основного канала не стоит гнать туда весь поток: сначала небольшой тестовый объём, потом остальное.
6. Поставьте лимиты скорости на каждый канал отдельно. Резервный обычно слабее основного, и без ограничения вы быстро упираетесь в его потолок.
7. Заведите единый журнал. Для каждого сообщения храните внутренний ID, имя провайдера, его message_id, статус, время отправки и время отчёта.

Если провайдер поддерживает шифрование сессии, включайте сразу: как настроить TLS для SMPP и защитить SMS-трафик — разбор параметров, которые обычно остаются по умолчанию. Шифрование заодно снижает число разрывов на промежуточном оборудовании.

Как выбрать момент для переключения

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

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

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

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

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

Что смотреть в аналитике после запуска

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

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

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

Ориентир по срочности: открываемость SMS достигает 98% в течение первых 90 секунд после доставки (обзор мобильных коммуникаций, smsblog.ru). Отсюда и вывод про порог переключения — минуты, а не часы. Если резерв включается через сорок минут, срочное уведомление о заказе теряет смысл само по себе. Пропускная способность крупных шлюзов при этом измеряется десятками и сотнями сообщений в секунду (notificore.ru), так что узкое место в резервировании — скорость обнаружения сбоя, а не скорость отправки.

Типичные ошибки

• Резервный канал существует только в договоре. Сессия не поднята, тестовых отправок не было, и в момент аварии вы настраиваете всё впервые.
• Разные имена отправителя у двух провайдеров. Клиент видит две подписи, а сравнить каналы по доставляемости уже нельзя.
• Переключение только после жалоб клиентов. Пока жалобы дойдут до менеджера, часть аудитории получит сообщение с опозданием на часы.
• Повтор без проверки журнала. Дубли раздражают сильнее, чем задержка.
• Логирование только успешных отправок. Ошибки и таймауты остаются без внимания именно тогда, когда нужны.
• Мгновенный возврат всего потока на основной канал. Дайте ему поработать на небольшом объёме хотя бы день.