DIDインシデントウィーク：メッセージング不通への対応とプリペイド管理

メッセージング不通はルーティング障害でありショップの在庫切れではない

新規プロビジョニングされた番号でメッセージングに失敗した場合、最初の直感として在庫確認や補充アラートのチェックを行うかもしれません。ホワイトレーベルCPaaSの運用において、倉庫や物理的な棚は存在しません。番号はJITプロビジョニングによって即座にインスタンス化されます。インバウンドのSMSやOTP配信が停止した場合、問題は「売り切れ」のボックスではなく、ルーティングテーブル、ウェブフックディスパッチャー、またはアップストリームゲートウェイのハンドシェイクに存在します。すべての障害をマーチャンダイジングのエラーではなく、ライブネットワーク例外として扱ってください。

割り当てと送信キューの即時凍結

クライアントからDLRのドロップやサイレントなOTPフローが報告され次第、自動番号割り当てと高ボリュームの送信スクリプトを直ちに凍結してください。アクティブな劣化中にスクリプトがルートの割り当てを続けさせると、影響範囲が拡大します。影響を受けるサブアカウントのプリペイド残高割り当てに一時的なホールドをかけます。サポートチームがHBおよびAPIペイロードのログを追跡している間、インシデントがアクティブなエンジニアリングレビュー中であることを明確に伝え、最低20米ドルのプリペイドフロアをそのまま維持します。

ネットワークを責める前の準備状況の検証

インシデントのエスカレーションを行う前に、影響を受ける番号がベースラインプロトコル要件を満たしていることを確認してください。多くの障害は、本番前のDIDメッセージング準備ガイドに記載されているバリデーション手順のスキップに起因します。10DLCの登録ステータス、ブランドコンプライアンス、ウェブフックURLの応答性を確認してください。ヘッダーが5xxエラーを返す場合、ボトルネックはキャリアネットワークではなくアプリケーションのエンドポイントにあります。

失敗したアセットの交換、返金、または解放

基盤となるルーティングパスが永続的に劣化し、SLAの制限時間内に復旧できない場合は、クライアントを放置しないでください。クリーンなスワップを実行するか、自動クレジットを発行します。DID発注失敗の返金と差し替えのプロトコルを確認し、残高の調整が正しく行われるようにします。テナントが障害を起こしたインフラストラクチャに対して二重支払いすることなく稼働中のアセットをプロビジョニングできるように、プリペイドホールドは直ちに解放されなければなりません。

ハネムーンフェーズを過ぎた財務的予測可能性

運用上のインシデントは、スケーリングのマイルストーンと重なることがよくあります。テナントが初期テストを終え、月額1,000米ドル前後のソフトレビューに近づくにつれ、トラフィックパターンは散発的なOTPバーストから持続的なA2Pキャンペーンへと移行します。DID 2ヶ月目：UTCカレンダー更新時のフルMRCのサイクルを注意深く監視し、アクティブなトラブルシューティング中に誤検知による不正サスペンションを引き起こすことなく、定期料金と利用状況のトップアップがクリーンに照合されるようにしてください。

ネイティブなホワイトレーベルの信頼性のためにIOSORから始める

DLR か messaging webhook が死んだら、その DID の送信キューを凍らせる。番号行がまだ assigned だからといって MT を続けるな。凍結時刻、最後の良い DLR、messaging-down 状態を出す。同じ桁での生きた smoke の後だけ再開する。店の欠品バッジでも請求の争いでもない。

IOSORの要点

messaging-down は凍結であり、在庫切れではない。

やる：キューを止め、テナントにメッセージが落ちたと伝える。やるな：送り続けること。DID を欠品在庫に貼り替えること。