IOSOR База знань

Інцидент з DID: збої повідомлень не пов'язані з наявністю товару

Як реагувати на перший збій розсилок, керувати холдами балансу без міфів про склад і тримати чесний статус для орендарів.

Інцидент з DID.

Зупинка доставки — це помилка маршрутизації, а не дефіцит

Коли на щойно виділеному номері зникають повідомлення, шукати залишки безглуздо. У white-label CPaaS немає фізичних полиць чи товарних залишків. Номери активуються через JIT-провижінінг. Якщо вхідні SMS чи OTP не надходять, проблема криється в таблицях маршрутизації, обробниках webhook або шлюзах. Будь-який збій слід розглядати як мережеву аномалію, а не як брак продукції на складі.

Негайне заморожування виділення та черг відправки

Щойно користувачі фіксують зникнення DLR або завислі OTP, негайно призупиняйте автоматичний розподіл номерів та масові відправки. Продовження видачі ресурсів під час аварії лише збільшує радіус ураження. Поставте баланс урахованих субаккаунтів на тимчасовий холд. Тримайте стандартну вимогу USD 20 мінімального депозиту активною, поки технічна підтримка аналізує логи HB та пакетів API.

Верифікація готовності перед пошуком проблем у мережі

Перш ніж передавати інцидент на вищий рівень, перевірте відповідність номера протоколам. Чимало хибних тривог виникають через недотримання вимог із матеріалу готовність DID-повідомлень до production. Перевірте реєстрацію 10DLC, відповідність бренду та доступність webhook-адреси. Якщо приймаючий сервер видає помилки 5xx, вузьке місце знаходить у коді клієнта, а не на магістралі.

Заміна, повернення чи вивільнення несправних ресурсів

Якщо магістральний маршрут остаточно деградував і не підлягає відновленню за SLA, не тримайте клієнта в невідомості. Проведіть швидку заміну або зарахуйте компенсацію. Дотримуйтесь процедури збій замовлення DID повернення і заміна для коректного перерахунку коштів. Предоплатний холд потрібно знімати миттєво, щоб орендаار міг підключити робочий номер без зайвих витрат.

Прогнозованість фінансів після стартового етапу

Технічні інциденты часто збігаються з масштабуванням бізнесу. Коли споживання орендаря наближається до м'якого аудиту біля USD 1,000/month, характер трафіку еволюціонує від коротких серій OTP до масштабних кампаній. Контролюйте цикли Другий місяць DID: повний MRC при зміні календаря UTC, щоб абонентська плата та пополнения проводилися без помилкових блокувань безпеки.

Почніть роботу з IOSOR

Коли падає DLR або messaging-webhook, заморозьте чергу надсилання на цьому DID. Не тримайте MT лише тому, що рядок номера досі assigned. Експортуйте час заморозки, останній живий DLR і статус messaging-down. Відновлюйте лише після живого smoke на тих самих цифрах. Це не бейдж «немає в наявності» і не суперечка за рахунок.

Підсумок IOSOR

Messaging-down — заморозка, не дірка в інвентарі.

Робіть: зупиніть черги й скажіть тенантам, що обмін повідомлень лежить. Не робіть: слати далі або перейменувати DID на «немає в залишку».

Чи був матеріал корисним?

Пов’язані гіди