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