DLR、延遲與備援：產品與財務的同一真相

產品要轉換。財務要可預測的借記。維運要一個在儀表板、webhook 與帳單裡含義相同的狀態詞。當 DLR、延遲與容錯切換分住三個孤島，每次事故都會變成詞彙之爭——團隊還在爭論時，預付費已經在燒。

IOSOR 以 white-label 預付費訊息運作，跨通道共用一套狀態字典——對客戶安全的錯誤，沒有外來品牌名稱。接近每月 USD 1,000+ 平台用量時，終態匯出、走廊延遲區間、以及每次容錯切換嘗試的借記，都會成為商業覆盤材料。先證據，後放量。目錄 live 與仍為 in setup 的走廊不是同一承諾。

給管理層的一張真相表

若無法從同一次匯出回答這三行，就還沒有「單一真相」。管理層不該用三張試算表拼月底。每層一份共用產物，是最便宜的停戰方式。產品、財務與維運在發送停止時應能指向同一列。

經得起稽核的 DLR 串接

• 簽章或認證的入站事件
• 帶 dedupe 鍵的冪等消費者
• 發送 → 狀態 → 帳本的關聯
• 產品內近期送達檢查

未簽章的 webhook 與非冪等消費者，會把重試變成重複工單與重複借記。參見 簡訊可達性營運指南 與 未送達、拒收與過期狀態。目錄標為 live 卻沒有 DLR 對到帳本，是財務無法辯護的承諾。每個終態都應留下可辯護的帳本痕跡。客服必須一眼分辨送達失敗與資金失敗。

延遲區間，而非虛榮平均

按走廊追蹤 accepted → submitted → delivered。OTP 轉換呈地理形狀；全球平均會掩蓋壞市場。延遲惡化時，用具名負責人決定重試、容錯切換或停止——不要靠希望。週報切開 p95/p99，讓一條弱走廊無法躲在世界均值後面。沒有負責人的延遲會變成未付費的重試迴圈。

有預付費紀律的容錯切換

容錯切換能救使用者，也能燒錢包：

1. 每則訊息限制自動嘗試次數。
2. 區分使用者重送與系統容錯切換。
3. 切勿切換到仍為 in setup 的目錄項。
4. 文件化每次嘗試的借記規則。

正式環境容錯鏈裡的模擬路由不是安全網。語音／簡訊回退請對照 語音告警與 OTP 回退。產品與財務應能匯出同一則訊息的每一次嘗試，並對齊 correlation ID。帳本上看不見的容錯切換，會偽裝成「轉換變好」，同時燒掉預付費。

危險訊號

• 介面把 delivered 與 sent 混用
• 容錯切換嘗試對財務不可見
• 正式環境容錯鏈裡有模擬路由
• webhook 與帳單的狀態詞不一致
• 只有截圖當證據
• 目錄仍為 in setup 卻承諾容錯切換
• 客戶端錯誤出現外來品牌名稱

開始使用 IOSOR

先鎖定一條走廊與一種訊息類型。把上週終態 DLR 匯出成產品與財務共用詞典，再用同一 correlation ID 走完預發、failover 與錢包扣款。模擬一次路徑切換，比對使用者看到的結果與帳本扣了什麼。財務若還掛著重試或 failover 扣款，畫面上就別再寫 Delivered。

IOSOR 要點

產品與財務要在同一 correlation ID 讀到同一則 DLR、同一套延遲與同一次 failover 結果。沒有對應使用者可見狀態的扣款就是說謊。

要做：公布對照表並匯出。不要：讓產品捏造財務拼不回來的狀態，或用綠色徽章擋住 failover 扣款。