Как подготовить резервный SMS-шлюз для бизнеса?

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

Каким сообщениям нужен резерв?

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

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

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

Как система должна переключаться на запасной канал?

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

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

Ответ «принято шлюзом» ещё не означает, что SMS появилась на телефоне. Если приложение получает отчёты о доставке, храните их отдельно от ответа на запрос отправки. Это позволит увидеть, на каком этапе остановилось сообщение, и не переключать весь трафик из-за одной неудачной доставки.

Что подготовить для подключения второго шлюза?

Попросите у резервного провайдера доступ к нужному способу отправки: HTTP API или SMPP. Затем проверьте, поддерживает ли он ваши направления, типы сообщений и имя отправителя. Условия лучше согласовать до интеграции: рабочее соединение само по себе ещё не подтверждает, что нужная SMS уйдёт по нужному маршруту.

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

Для небольшого бизнеса отправка через HTTP API часто означает меньше изменений в приложении, если оно уже умеет делать такие запросы. SMPP имеет смысл рассматривать, когда приложение работает с этим протоколом или ему нужен отдельный контроль соединения и очереди. На smpp.by для такой задачи уместны подключение шлюза, API-интеграция и анализ трафика: они помогают увидеть, где задержка возникла ещё до перехода на резерв. Схему подключения запасного провайдера можно дополнительно посмотреть в статье на rocketsms.by.

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

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

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

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

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

Какие ошибки чаще всего мешают резервной отправке?

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

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