IOSOR База знаний
Инцидент с DID: сбои обмена сообщениями не связаны с наличием
Как действовать при первом сбое рассылок, управлять холдированием баланса без иллюзий склада и сохранять честность перед клиентами.
Инцидент с DID.
Сбой рассылки — это проблема маршрутизации, а не пустой склад
Когда на свежевыделенном номере перестают ходить сообщения, нельзя искать «остатки на полке». В белой маркировке CPaaS нет физических складов: номера активируются через JIT-выделение. Если входящие SMS или OTP перестали поступать, ищите причину в таблицах маршрутизации, диспетчерах webhook или шлюзах. Относитесь к каждому сбою как к сетевому исключению, а не к нехватке товара.
Немедленная заморозка выдачи и очередей отправки
Как только клиенты сообщают о пропавших DLR или неотправленных OTP, сразу останавливайте автоматическое назначение номеров и массовые рассылки. Продолжение выделения маршрутов во время деградации только увеличивает масштаб проблемы. Заморозьте списания с предоплаченного баланса для пострадавших субклиентов. Убедитесь, что ваш минимальный депозит в USD 20 защищает систему, пока инженеры изучают логи HB и полезную нагрузку API.
Проверка готовности перед обвинением сети
Прежде чем передавать тикет на эскалацию, проверьте базовые требования протоколов. Многие мнимые сбои возникают из-за пропущенных шагов проверки из руководства готовность DID-сообщений до production. Проверьте статус регистрации 10DLC, брендинг и доступность адреса webhook. Если сервер отвечает ошибками 5xx, проблема в приложении клиента, а не на стороне оператора.
Замена, возврат или освобождение проблемных активов
Если маршрут окончательно деградировал и не восстанавливается в рамках SLA, оперативно проведите замену номера или оформите возврат средств. Следуйте инструкциям для сценария сбой заказа DID refund и swap, чтобы корректно скорректировать баланс. Холд по предоплате должен сниматься сразу, чтобы арендатор мог взять рабочий ресурс без двойных списаний.
Финансовая стабильность после тестового периода
Операционные инциденты часто совпадают с ростом объемов. Когда клиент преодолевает порог мягкой проверки возле USD 1,000/month, характер трафика меняется от редких OTP к массовым A2P-кампаниям. Следите за расчетами Второй месяц DID: полный MRC при смене календаря UTC, чтобы регулярная абонентская плата и пополнения сходились без ложных срабатываний антифрода.
Начните работу с IOSOR
Когда умирает DLR или messaging-webhook, заморозьте очередь отправки на этом DID. Не продолжайте MT только потому, что строка номера всё ещё assigned. Выгрузите время заморозки, последний живой DLR и статус messaging-down. Возобновляйте только после живого smoke на тех же цифрах. Это не бейдж «нет в наличии» и не спор по счёту.
Итог IOSOR
Messaging-down — заморозка, не дыра в инвентаре.
Делайте: остановите очереди и скажите тенантам, что обмен сообщений лежит. Не делайте: слать дальше или переименовать DID в «нет в наличии».
Был ли материал полезен?
Связанные гайды
- Передача DID второму владельцу: правила назначения и высвобождения
Контроль операционных границ, JIT-провижининга и финансовых порогов при передаче DID номеров.
- Лимит расходов на один номер: аренда плюс исходящий трафик
Управляйте рисками по каждому номеру в white-label CPaaS платформе с помощью объединенного лимита на MRC и исходящий трафик.
- Маршрутизация входящих вебхуков по DID: MO без владельца теряет STOP
Надежная маршрутизация входящих вебхуков в белом лейбле. Предотвращение сиротских MO и потерянных запросов отписки.