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