Перенос DID: точечное тестирование перед основным трафиком

Перенос. Живой smoke на перенесённом DID идёт до объёма, не после бейджа complete.

1. Статус завершения переноса — это сигнал, а не зеленый свет

Когда статус запроса на перенос DID меняется на завершенный в консоли, это означает лишь обновление записи в центральном реестре маршрутизации. Это не гарантирует, что абсолютно все операторы связи мгновенно обновили свои таблицы LRN или что входящие вебхуки SMS обрабатываются корректно. Переключение всего продакшн-трафика на только что перенесенный номер E.164 сразу после завершения процедуры часто приводит к потере OTP, тихим сбоям входящих сообщений и негативу пользователей. Операционная безопасность требует воспринимать статус завершения как команду к точечной проверке, а не как разрешение открывать шлюзы.

2. Шаг 1: Точечная проверка входящих и исходящих сообщений

Перед отправкой реального трафика приложения выполните контрольные тесты в изолированных условиях. Отправьте тестовые SMS на перенесенный номер с разных мобильных сетей и убедитесь, что входящий webhook срабатывает с корректной полезной нагрузкой. Проверьте, возвращают ли исходящие ответы валидные статусы DLR без ошибок доставки. Тестирование обоих направлений на минимальной скорости позволяет выявить аномалии маршрутизации или неполное обновление таблиц операторов до того, как клиенты столкнутся с задержками кодов авторизации.

3. Шаг 2: Доставка вебхуков и формат E.164

Маршрутизация входящих сообщений критически зависит от точного формата JSON в вебхуках и строгой стандартизации E.164. Убедитесь, что ваши эндпоинты принимают уведомления в рамках стандартного SLA. Проверьте, что номера сохраняют полный международный формат без пропущенных кодов стран. При вызове процедур JIT или активации перенесенного DID платформа динамически резервирует и связывает маршруты. Если вебхуки возвращают ошибки HTTP 5xx или не проходят проверку подписи во время тестовых прогонов, немедленно исправьте работу приложения до запуска пользователей.

4. Шаг 3: Постепенный разгон трафика и минимальный баланс

Увеличение нагрузки на перенесенные номера должно происходить ступенчато: 5%, 25%, 50% и затем 100% в течение нескольких часов или дней. Это защищает репутацию доставки и позволяет контролировать баланс в реальном времени. Напоминаем, что биллинг платформы работает на основе предоплатного биллинга. Поддерживайте остаток выше порога USD 20 prepaid floor, чтобы избежать остановки отправки при скачках трафика. Когда ежемесячный оборот приближается к отметке soft review near USD 1,000/month, параметры аккаунта проверяются для сохранения высокой пропускной способности.

5. Протоколы проверки и операционные сценарии

Чтобы построить надежную архитектуру обмена сообщениями, объедините процесс верификации переноса с чек-листами запуска и стратегиями динамического назначения номеров. Изучите следующие руководства:

• Чек-лист запуска OTP: защита предоплатного бюджета в первую неделю
• портирование или новый DID
• Правда о предоплате: что IOSOR никогда не обещает

6. Начните с IOSOR

Когда статус переноса стал complete — сначала точечный smoke, не поток. Отправьте один inbound и один outbound на перенесённый E.164. Подтвердите payload webhook и терминальный DLR. Только потом 5, 25, 50, затем 100. Выгрузите окно smoke — объём не должен быть догадкой.

Итог IOSOR

Complete — приглашение к smoke, не зелёный свет объёму.

Делайте: smoke в обе стороны, потом ступени. Не делайте: blast в час, когда консоль сказала complete.