Как настроить failover между SMPP-провайдерами и не терять SMS

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

Что такое failover и когда он нужен?

Failover — это механизм, который автоматически переключает отправку SMS с основного SMPP-подключения на резервное, если основное перестало отвечать. Такой сценарий критичен для транзакционных сообщений: кодов подтверждения, одноразовых паролей, уведомлений о статусе заказа. Если канал недоступен, клиент не получит SMS, а заказ может «зависнуть».

В протоколе SMPP v3.4, который сейчас используют почти все шлюзы, нет встроенной команды «переключиться на резервный сервер». Логика failover ложится на отправителя: либо на сервис рассылок, либо на вашу систему. Для малого бизнеса это часто звучит сложнее, чем есть на самом деле. Первый вариант — использовать SMS-агрегатора, у которого уже настроено резервирование. Второй — организовать собственное резервное подключение. Ниже разберём второй вариант. Если хотите разобраться в деталях, почитайте отдельную статью о настройке резервного SMPP-канала.

Как настроить failover между двумя SMPP-провайдерами?

Самостоятельная настройка сводится к нескольким шагам. Даже без глубокого опыта с SMPP по ним можно пройти за день.

1. Выберите двух провайдеров. У каждого должен быть собственный маршрут до операторов и независимая инфраструктура. Если оба подключения пойдут через одну компанию-агрегатора, смысл failover теряется.
2. Получите параметры подключения у обоих: адрес сервера, порт, системный ID, пароль. Уточните версию протокола — желательно, чтобы оба поддерживали SMPP v3.4.
3. Настройте основное и резервное соединения в вашей системе. Сделайте тестовую отправку через каждого провайдера по отдельности. Оба должны работать.
4. Определите критерий отказа. Регулярно отправляйте команду enquire_link — это проверка связи с сервером. Если ответа нет несколько раз подряд (например, три попытки с интервалом 10 секунд), считайте соединение потерянным.
5. Пропишите алгоритм переключения. При отправке пробуйте основной канал. Если в течение разумного времени нет подтверждения приёма, отправляйте то же сообщение через резервный. Уникальный идентификатор сообщения при этом должен сохраняться, чтобы не создать дубль.
6. Протестируйте переключение. Временно заблокируйте основное соединение и отправьте тестовое SMS. Оно должно уйти через резервный шлюз.

Помните одну особенность SMPP: статусы доставки (DLR) не всегда приходят на то же соединение, через которое было отправлено сообщение. При нескольких подключениях к одному логину или после переключения это случается регулярно. Поэтому всегда сопоставляйте DLR по внутреннему идентификатору сообщения, а не по номеру соединения.

Почему возникают дубли и как их избежать?

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

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

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

Настроенный failover без теста — это просто обещание. Чтобы убедиться, создайте сбой своими руками. Отправьте тестовое SMS через основного провайдера, получите DLR. Затем заблокируйте доступ к основному серверу или остановите SMPP-процесс в своей системе. Отправьте ещё одно SMS — оно должно автоматически уйти через резервный шлюз. Проверьте, что DLR корректно отобразился в вашей системе. Повторите сценарий в обратную сторону, чтобы убедиться, что основной канал тоже работает после возврата.

Для контроля качества переключения важно понимать, как читать DLR-отчёты. Пять ключевых метрик разобраны в статье Как читать DLR-отчёт SMPP-шлюза. Если вы отправляете SMS через CRM, настройку соединений обычно делают один раз, а дальше система работает автоматически. Готовый сценарий описан в инструкции по интеграции CRM и SMPP для SMS-уведомлений.

Типичные ошибки при настройке failover

• Выбор двух провайдеров, которые используют один и тот же вышестоящий маршрут. При сбое общего узла отключаются оба канала.
• Отсутствие мониторинга. Если соединение не проверяется, система продолжит отправлять на мёртвый шлюз до тех пор, пока не упадёт очередь.
• Повторная отправка без дедупликации. Дубль для кода подтверждения хуже, чем отсутствие SMS: клиент вводит второй код и получает ошибку.
• Игнорирование DLR. Если не обрабатывать статусы, вы не узнаете о недоставке, пока клиент не пожалуется.
• Нет тестирования переключения. Схема может отлично выглядеть в документации, но в первый реальный сбой окажется нерабочей.