Как настроить резервный SMS-шлюз для бизнеса?
Резервный SMS-шлюз помогает отправлять коды входа и уведомления о заказах, когда основной канал перестал принимать сообщения. Для этого бизнес заранее подключает второго провайдера, а в своей системе задаёт правила переключения. Сам по себе запасной аккаунт проблему не решит: нужно проверить отправку, разобраться со статусами и исключить повторные сообщения. Ниже — порядок действий для интернет-магазина или сервиса, который отправляет SMS через API.
Какие сообщения стоит отправлять через резерв?
Начните со списка SMS, задержка которых мешает клиенту закончить действие. Покупатель ждёт код входа, чтобы открыть личный кабинет. После оформления заказа он ждёт подтверждение, чтобы понимать, принял ли магазин покупку. Если такие сообщения зависят от одного шлюза, его сбой сразу затрагивает работу сайта.
Разделите сообщения по назначению. Для кодов входа обычно важна быстрая повторная попытка через резерв. Подтверждение заказа система иногда может задержать, если покупатель уже видит заказ в личном кабинете. Правило выбирайте для каждого типа SMS отдельно: одинаковое переключение для всех сообщений создаст лишние отправки.
Составьте короткую таблицу для своей команды: тип сообщения, событие, которое запускает отправку, и действие при сбое основного шлюза. В неё же запишите, кто проверяет результат. С этого документа разработчику проще начать подключение CRM к SMS-шлюзу через API, если уведомления уходят из CRM.
Когда система должна переключаться на второй шлюз?
Сначала уточните, на каком этапе пропала связь. Основной шлюз мог отклонить запрос, не ответить на него или принять SMS, после чего статус доставки ещё не пришёл. Для системы это разные ситуации. Если запрос не получил ответа, сообщение могло попасть к провайдеру; немедленная отправка через резерв тогда грозит дублем.
| Что видит ваша система | Что делать |
| Шлюз явно отклонил запрос | Проверить причину отказа. Если она связана с доступностью канала, отправить через резерв. |
| Шлюз не ответил на запрос | Сначала выяснить, принял ли он сообщение. Если это нельзя определить, выбрать правило, которое учитывает риск дубля. |
| Шлюз принял сообщение, статус доставки ещё не пришёл | Не считать задержку статуса сбоем отправки. Дождаться ответа в пределах выбранного для этого сообщения времени. |
| Шлюз вернул ошибку доступа или нехватки средств | Сообщить ответственному и отдельно проверить, разрешена ли отправка через резерв. |
Условия переключения запишите простыми словами до настройки кода. Например: «При явном отказе основного шлюза отправляем код входа через резерв; при неизвестном результате сначала проверяем состояние запроса». Затем разработчик переведёт это правило в логику системы. Для контроля пригодится материал о том, какие показатели SMS-шлюза отслеживать.
Как подключить резерв и не отправить клиенту два SMS?
Заведите доступ ко второму провайдеру заранее и согласуйте, какие сообщения и направления он сможет обслуживать. Проверьте баланс, имя отправителя, способ передачи статусов и ограничения API. Если основной и резервный шлюзы настроены по-разному, зафиксируйте различия: при аварии времени разбирать их уже не будет.
В вашей системе каждому событию нужен свой внутренний идентификатор. Сохраните рядом с ним текст SMS, выбранный шлюз, ответ на запрос и последний известный статус. Тогда при сбое сотрудник увидит, была ли попытка отправки и что о ней известно. Перед повтором система сверяется с этой записью и не создаёт ещё одно SMS по тому же событию без проверки.
С кодами входа добавьте отдельное правило: если система выпустила новый код, старый не должен внезапно прийти и запутать пользователя. Какой код остаётся действительным, решает ваш сервис. Второй шлюз лишь доставляет текст, который вы ему передали.
Настройку переключения делает система отправителя. Если нужен ориентир для разговора с разработчиком о подключении второго канала, схема резервной отправки описана в статье на rocketsms.by. Для PostSMS такая задача также относится к интеграции SMS API: полезно сразу предусмотреть журнал попыток и отчёт по отправкам через каждый шлюз.
Как проверить резерв до настоящего сбоя?
Отправьте тестовое сообщение через резервный канал на доступный вам номер и проверьте весь путь: запрос ушёл из вашей системы, шлюз его принял, статус вернулся, запись появилась в журнале. Проверяйте тот же тип сообщения и то же направление, которые планируете использовать в работе. Успех теста с одним SMS ещё не подтверждает, что остальные сценарии настроены верно.
Затем разыграйте отказ основного шлюза в тестовой среде. Посмотрите, какое условие запустило переключение, сколько попыток создала система и какой статус увидит сотрудник. Отдельно проверьте запрос без ответа: здесь легче всего получить два одинаковых сообщения. Если статус задержался, полезно заранее определить, когда отправлять покупателю SMS при задержке обновления статуса.
После теста оставьте сотруднику понятный способ проверить резерв: где видны ошибки, где смотреть отправки через запасной канал и кому сообщить о сбое. Если о переключении узнают только из жалобы покупателя, мониторинг не выполняет свою задачу.
Какие ошибки чаще всего мешают резервной отправке?
- Подключили второй шлюз, но не задали условие переключения. Исправление: записать правило для каждого важного типа SMS и проверить его в тесте.
- Считают отсутствие статуса доставки отказом шлюза. Исправление: различать ответ на запрос и последующий статус сообщения.
- Повторяют отправку после любого сбоя связи. Исправление: сохранять идентификатор события и проверять результат предыдущей попытки.
- Тестируют только доступ к API. Исправление: отправить SMS по нужному направлению и проследить статус до журнала вашей системы.
- Не замечают, что резерв начал работать. Исправление: настроить уведомление сотруднику о переключении и регулярно смотреть отчёт по каналам.
Начните с одного действия: откройте список SMS, которые отправляет ваш сайт, и отметьте сообщение, задержка которого первой остановит клиента. Для него и задайте правило резервной отправки.
