DLR、延迟与故障转移：产品与财务的统一真相

产品要转化，财务要可预测的借记，运维要一个在仪表盘、webhook 与账单里含义相同的状态词。当 DLR、延迟与 failover 分属三套口径，每次事故都会变成词汇之争——预付费在争吵中被烧掉。

IOSOR 以 white-label 预付费消息运行，跨通道共用一套状态字典，错误对客户端安全，不把外来品牌名倾倒给买家。目录能力标 live 才对外承诺；in setup 不是 live。接近每月 USD 1,000+ 平台用量时，终态导出、走廊延迟区间与每次 failover 尝试的借记，会成为更紧密的商务复盘材料。先拿证据，再谈扩量。

管理层的一张真相表

若无法从同一次导出回答这三行，就还没有「单一真相」。管理层不应在月末用三张表拼账。每层一个共享产物，是最便宜的停战方式：评审时打开同一份文件，而不是事后补幻灯片。

经得起审计的 DLR 串接

• 入站事件须签名或认证
• 消费者幂等，并用稳定键去重
• 发送 → 状态 → 账本全程可关联
• 产品内可检查近期送达，不必翻原始日志

未签名的 webhook、非幂等消费者，会把重试变成重复工单和重复借记。对照 短信可达性运营指南 与 未送达、拒收与过期状态。目录标 live 却无法把 DLR 关联到账本，是财务无法辩护的承诺。值班应能用一条关联 ID 从发送追到终态再追到借记行。webhook 里的 undelivered / rejected / expired 若与账单含义不同，这套串接经不起审计。

延迟区间，而非虚荣平均

按走廊跟踪 accepted → submitted → delivered。OTP 转化呈地理形状：全球平均会把一条坏走廊藏进「看起来还行」的均值。延迟恶化时，必须用具名负责人在重试、failover 与停止之间做决定——不能靠希望。周报切开 p95/p99，弱走廊无法躲在世界均值后面。没有主人的延迟，会变成无人认领的重试环，预付费先于转化被烧光。

有预付费纪律的故障转移

Failover 能救用户，也能烧钱包：

1. 每条消息限制自动尝试次数。
2. 区分用户重发与系统 failover。
3. 切勿 failover 到仍为 in setup 的目录项。
4. 写明每次尝试的借记规则。

生产 failover 链里的 mock 路由不是安全网。语音/SMS 回退对照 语音告警与 OTP 回退。产品与财务应导出同一条消息的全部尝试并对齐关联 ID。先给重试设上限，再让 failover 变成死走廊上的昂贵循环。

危险信号

• 界面把 delivered 与 sent 混用
• failover 尝试对财务不可见
• 生产 failover 链里出现 mock 路由
• webhook 与账单使用不同状态词
• 只有截图当证据
• 目录仍为 in setup 却承诺 failover
• 客户端错误出现外来品牌名称

开始使用 IOSOR

选定一条走廊和一种消息类型。把上周的终态 DLR 导出到产品与财务共用词典，再用同一 correlation ID 贯穿预发、failover 和钱包扣款。模拟一次路径切换，核对用户看见的结果与账本扣了什么。若财务仍挂着重试或 failover 扣款，界面就不要再写 Delivered。

IOSOR 要点

产品与财务必须在同一 correlation ID 上读到同一条 DLR、同一套时延和同一次 failover 结果。没有对应用户可见状态的扣款就是撒谎。

要做：公布对照表并导出。不要：让产品编造财务还原不了的状态，或用绿色徽章挡住 failover 扣款。