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