огда одноразовый пароль не приходит, пользователь застревает на экране входа в систему или оформления заказа и находится всего в одном шаге от отказа от покупки. Для команды разработчиков неприятно то, что сообщение часто отправляется корректно — API возвращает код 202, отправка SMPP-запроса принята, платформа отображает сообщение в очереди. Сбой происходит где-то на нижестоящем уровне, который команда разработчиков приложения не может увидеть напрямую. В этой статье рассматривается конечный список причин сбоев одноразовых паролей в производственной среде, как отличить их от имеющихся чеков и каковы схемы устранения проблемы для каждой из них.
Площадь поверхности разрушения меньше, чем кажется.
Сбой передачи OTP-трафика происходит по одной из семи причин, примерно в таком порядке частоты: отклонение идентификатора отправителя у оператора назначения, пропуск сообщения через «серый маршрут», ограничение скорости на SMSC или межсетевом экране, срабатывание контентных фильтров на шаблоне, несоответствие кодировки между содержимым UCS-2 и шаблоном GSM-7, перегрузка сети у оператора назначения и недоступность самого телефона (выключен, вне зоны покрытия, переадресация с устаревшей маршрутизацией). Все остальное — поврежденный MSISDN, просроченные учетные данные, события обрыва маршрута — составляет небольшое меньшинство. В первую очередь следует диагностировать наиболее распространенные случаи.
Внимательно изучите отчёты о доставке, а не ответ на отправленное сообщение.
Самая большая ошибка, которую допускают команды, — это рассматривать успешную отправку (код 202 от HTTP, ESME_ROK в submit_sm) как доказательство доставки сообщения. Это не так. Отправка означает, что платформа приняла сообщение; доставка означает, что устройство его получило. Каждая система OTP должна быть связана с отчётом о доставке (DLR), который поступает позже в виде веб-хука или PDU deliver_sm и содержит один из небольшого набора кодов состояния: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. Первым сигналом для любого расследования OTP является распределение статуса DLR по маршруту, идентификатору отправителя, оператору назначения и временному окну, а не процент успешных отправок.
Проведите диагностику, определив место возникновения неисправности.
Чистое расследование с использованием одноразового пароля (OTP) разделяет сбой на четыре сегмента и работает в обратном порядке, начиная с самого нижнего сигнала. Сегмент 1: сбой при отправке — платформа отклонила вызов до того, как он был отправлен, почти всегда из-за некорректного идентификатора отправителя, незарегистрированной категории шаблона, неподдерживаемой страны или отсутствия обязательного поля. Сегмент 2: принят при отправке, но так и не доставлен в целевой SMSC — обычно из-за проблемы с качеством маршрутизации или блокировки брандмауэром. Сегмент 3: доставлен в SMSC и вернул отрицательный DLR — контент отфильтрован, идентификатор отправителя занесен в черный список оператора, получатель заблокирован. Сегмент 4: положительный DLR, но пользователь не сообщает о сообщении — телефон выключен, перенесен к другому оператору с устаревшей маршрутизацией, спам-фильтр на уровне ОС или уведомление подавлено. Способы устранения проблемы различаются в каждом сегменте; смешивание их может привести к неправильному решению.
Семь распространенных причин и что делать в каждом случае.
1. Отклонение идентификатора отправителя
На многих регулируемых рынках — ОАЭ в рамках TDRA, Саудовская Аравия в рамках CST, Египет в рамках NTRA, Индия в рамках DLT TRAI — требуется предварительная регистрация каждого буквенно-цифрового идентификатора отправителя в отношении проверенного юридического лица. Трафик, отправленный под незарегистрированным идентификатором, отклоняется на границе оператора и приводит к отрицательному DLR без доставки сообщения, но с ответом на запрос 202. Решение заключается в регистрации, а диагностика состоит в сопоставлении UNDELIV/REJECTD с идентификатором отправителя и страной назначения: если все ошибки связаны с одним и тем же идентификатором отправителя в одной стране, проблема в регистрации. См. руководство по регистрации идентификаторов отправителей для рынков стран Персидского залива для получения подробной информации о необходимых документах.
2. Пересадки по «серым» маршрутам
Дешевые международные маршруты часто включают один или несколько переходов через партнерские агрегаторы или терминалы SIM-ферм. Каждый переход увеличивает задержку, повышает вероятность скрытого обрыва соединения и увеличивает вероятность того, что межсетевой экран оператора назначения классифицирует трафик как несанкционированный A2P и блокирует его. Характерными признаками являются высокая частота UNDELIV, высокая вариативность задержки и резкое падение скорости доставки, когда оператор назначения развертывает или обновляет SMS-межсетевой экран. Решение заключается в переносе OTP на прямой маршрут оператора; компромисс обсуждается в прямые маршруты против серых маршрутов.
3. Регулирование скорости на уровне SMSC или межсетевого экрана.
Каждый оператор и каждый межсетевой экран устанавливают потолок количества отправленных сообщений в секунду (TPS) для каждого идентификатора отправителя и каждого маршрута. При превышении этого потолка сообщения либо немедленно отклоняются (в лучшем случае — вы видите сбой), либо ставятся в очередь и доставляются с задержкой (в худшем случае — они приходят после истечения срока действия OTP, и пользователь уже отказался от дальнейшего взаимодействия). Диагностика заключается в сравнении пиков отправки с задержкой p95: стабильная кривая задержки при постоянной нагрузке, которая резко возрастает во время пиков, указывает на ограничение скорости. Решение состоит в ограничении скорости на уровне приложения для сглаживания пиков и согласовании более высокого потолка TPS специально для трафика класса OTP.
4. Фильтры контента
Классификаторы содержимого операторов и межсетевых экранов могут выявлять шаблоны одноразовых паролей (OTP), содержащие ключевые слова, URL-адреса (большинство операторов активно борются с непроверенными короткими ссылками в транзакционном контенте), необычные имена отправителей или макеты, напоминающие известные фишинговые схемы. Характерной чертой является внезапное увеличение количества отклоненных запросов (REJECTD) в одном шаблоне, в то время как все остальные запросы обрабатываются без проблем. Решение заключается в гигиеничности шаблона: короткий, стандартный текст OTP, отсутствие коротких ссылок, отсутствие формулировок, создающих ощущение срочности. Если шаблон регулируется (на некоторых рынках транзакционные шаблоны должны быть предварительно зарегистрированы), убедитесь, что зарегистрированная версия соответствует отправляемой версии — небольшие расхождения будут обнаружены.
5. Несоответствие кодировки
Шаблоны OTP, содержащие символы, не являющиеся символами ASCII (гласная с диакритическим знаком, специальная кавычка, скопированная из проектной документации, арабская цифра), незаметно преобразуют сообщение из GSM-7 в UCS-2, уменьшая допустимое количество символов на сегмент со 160 до 70 и вызывая объединение сообщений, которые некоторые старые телефоны неправильно компилируют. Диагностика заключается в проверке фактического сгенерированного шаблона побайтно, а не шаблона в том виде, в котором его видит разработчик. Решение состоит в проверке шаблона с учетом кодировки и проверке во время сборки, которая выявляет любые символы, не являющиеся символами GSM-7, в транзакционном шаблоне.
6. Перегрузка сети
В периоды крупных событий (Ид, Черная пятница, национальные праздники, масштабные сбои) каналы SMSC операторов-получателей иногда дают сбой — заявки принимаются, но задержки доставки возрастают от долей секунды до многих минут. На стороне отправителя нет простого решения; задача состоит в обнаружении проблемы (резкий рост задержки p95 по всем маршрутам к одному оператору) и переключении на альтернативный канал до закрытия окна OTP.
7. Телефон недоступен
Небольшая, но устойчивая часть сбоев OTP не связана с инфраструктурой — телефон выключен, находится вне зоны покрытия, в режиме полета, спам-фильтр оператора блокирует неизвестных отправителей или телефон был переведен к новому оператору, и таблицы маршрутизации не сошлись. Подпись представляет собой просроченные или неизвестные DLR, разбросанные по всем маршрутам и идентификаторам отправителей без концентрации у оператора. Решение заключается в цепочке резервных путей, описанной ниже.
Создайте диагностическую панель один раз и используйте её постоянно.
Большинство расследований OTP-запросов заходят в тупик, потому что команда работает с необработанными логами под давлением. Команды, которые быстро восстанавливаются, используют постоянную панель мониторинга с пятью виджетами: распределение статуса DLR по операторам назначения (самый полезный график), сквозная задержка p50/p95/p99 для каждого маршрута, скорость доставки на уровне идентификатора отправителя, скорость доставки на уровне шаблона контента и временной ряд от отправки до доставки в реальном времени за последний час. Создайте эти инструменты один раз. Они определяют разницу между диагностикой за сорок минут и за четыре часа.
Эффективные методы устранения проблем
Прямая привязка только для OTP.
Массовый маркетинговый трафик и трафик OTP не должны использовать один и тот же маршрут или привязку. Маркетинговый трафик чувствителен к затратам, устойчив к задержкам и может проходить по оптовым маршрутам; трафик OTP критически важен с точки зрения задержек и доставляемости, и требует прямой привязки. Совместное использование этих потоков означает, что всплеск маркетингового трафика перегружает путь OTP, а шаблонный фильтр маршрутов маркетинга ухудшает репутацию маршрута для OTP.
Резервная цепочка, автоматическая и с ограничением по времени.
При проектировании системы учитывалось предположение, что любой отдельный канал может иногда давать сбои, и соответствующим образом разрабатывалась цепочка резервных вариантов: сначала шаблон аутентификации WhatsApp или RCS, если пользователь доступен по любому из этих каналов, SMS в качестве универсального резервного варианта, голосовой OTP в качестве последнего средства. Резервный вариант должен быть автоматическим (без повторной попытки вручную со стороны пользователя), ограниченным по времени (время ожидания до переключения на резервный канал короче, чем время ожидания пользователя — обычно от 8 до 15 секунд) и условным (не переключаться на резервный канал при положительном значении DLR; переключаться на резервный канал при истечении времени ожидания или отрицательном значении DLR). Сам код OTP должен генерироваться один раз и использоваться повторно на разных каналах, чтобы пользователю не предоставлялись два действительных кода.
Исключайте дубли при каждой повторной попытке
Когда пользователь нажимает «повторная отправка» или приложение автоматически повторяет попытку, проверяйте, прежде чем отправлять снова. API BroadNet не принимает ключ идемпотентности, поэтому дедупликация — задача вашего кода: фиксируйте каждую отправку до её выполнения, сохраняйте идентификатор сообщения, который возвращает API, и проверяйте статус этого сообщения перед любой повторной отправкой (см. идемпотентность и безопасные повторы). Без такой проверки медленная, но успешная первая отправка и автоматическая повторная отправка приведут к появлению двух одноразовых паролей в почтовом ящике пользователя, пользователь использует более старый, проверка не удается, и команда обвиняет службу OTP, хотя ошибка заключалась в логике повторных попыток.
Голосовой резерв для длинного хвоста
Примерно один процент пользователей в любой конкретный день не получает SMS-сообщение ни по одной из вышеперечисленных причин, и этот один процент — это тот, кто в основном обращается в службу поддержки. Голосовой OTP — звонок, в котором код зачитывается вслух, — решает почти все эти проблемы. Это разница между раздраженным пользователем, который пробует другой браузер, и растерянным пользователем, который сдается.
Сервис BroadNet OTP обрабатывает прямую привязку, цепочку резервных соединений и эскалацию голосовой связи за одним вызовом API, возвращает идентификатор сообщения, который можно проверить перед повторной отправкой — и предоставляет информацию о распределении DLR по каналам и операторам, на которой основано приведенное выше руководство по диагностике.
Как выглядит хороший результат в цифрах
Хорошо оснащенная система OTP, отправляющая сообщения на регулируемый рынок стран Персидского залива по прямым маршрутам операторов и имеющая работающую резервную цепочку, должна обеспечивать: 99%+ сквозной проверки (пользователь успешно подтвердил получение сообщения, а не просто его доставку), задержку p95 менее пяти секунд на основном канале и измеримую, но небольшую (1-3%) вероятность перехода на резервный канал. Если ваши показатели существенно хуже, проблема почти наверняка связана с одной из семи причин, перечисленных выше — диагностируйте, а не гадайте.
Рекомендуемая литература
- SMS API против SMPP — что лучше для предприятий?
- Как банкам следует отслеживать доставку OTP-кодов и мошенничество
- Как экспресс-верификация звонков влияет на доходы операторов A2P
- Глоссарий — что такое OTP, что такое DLR, что такое проверка Flash-Call
- Страницы продуктов — Сервис OTP и Голосовой OTP MyOTP
- Покрытие — Маршрутизация A2P SMS и OTP в ОАЭ