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

Перенесення. Живий smoke на перенесеному DID іде до обсягу, не після бейджа complete.

1. Завершення переносу номеру — лише сигнал до перевірки

Зміна статусу переносу DID на завершений у консолі означає лише оновлення запису в центральному реєстрі маршрутизації. Це не дає гарантії, що всі оператори зв'язку вже оновили свої LRN-таблиці або що вхідні вебхуки SMS обробляються належним чином. Переключення основного навантаження на щойно перенесений номер E.164 одразу після завершення процедури нерідко спричиняє втрату OTP, приховані збої та невдоволення користувачів. Операційна дисципліна вимагає сприймати факт переносу як сигнал до тестової перевірки, а не як дозвіл вмикати максимальний потік.

2. Етап 1: Тестування вхідного та вихідного потоку SMS

Перед спрямуванням реального трафіку вашого сервісу здійсніть контрольній прогон у повністю керованих умовах. Надішліть тестові 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.