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