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