旧 webhook 必须先排空再切密钥

旧 webhook 仍持有 in-flight DLR 时切密钥，会把投递真相扔在半空。买家看到 sent 却无最终状态；财务看到永不关闭的 hold；ops 失去证明 failover 顺序的轨迹。先排空。再切割。

IOSOR 轮换把旧 endpoint 当作必须安静的队列——不是新 URL 答了一次 smoke 就扳动的开关。in-flight 报告属于消息生命周期；孤儿化它们会发明一周幽灵行。

清点旧 endpoint 上的 in-flight DLR

导出绑定旧 webhook URL 的未完成投递与 pending 最终状态。给每行打上年龄与 message id。这份清单是排空 backlog——不是「重试总会跑完」的模糊希望。

在任何人安排密钥吊销前把导出交给财务。若 backlog 超过一个安静班次，书面延长排空窗口，而不是切进晚到 DLR 风暴。

排空到 quiet，然后切密钥

旧 endpoint 仅对 completion 事件保持 Live，直到清单归零或约定残留下限。排空列表仍有新到达时，不要吊销 messaging 或 webhook 密钥。quiet 是测量窗口内无新 final——不是「Slack 看起来平静」。

quiet 证明后，在与唯一所有者 URL 切换同一变更窗口吊销旧密钥。留下半活密钥的部分吊销，会让晚到 DLR 落在死路径。

排空期间保持 failover 顺序诚实

排空时不要发明绕过有序备份故事的第二条 Live 路径。failover 仍是 primary-then-backup；排空不是扇出许可。写明哪条路径拥有 in-flight 行，避免事故周争论哪根管子「本该」应答。

若 primary 在排空中途失败，走有序备份并重新清点——不要用恐慌式切密钥来「简化」。

切割后重新证明 day-1 runway

切密钥后跑 day-1 必须绿灯的检查：heartbeat、发送证明、新 endpoint 的 webhook finals、钱包 hold 关闭。然后才重开试点量。旧路径已排空但 runway 仍红，仍是被挡的上线。

导出新 URL 上第一个安静小时，让 ops 向买家证明 DLR 没有随旧密钥消失。

相关运维路径

• 在不丢失交付报告的情况下轮换 Webhook 签名密钥
• 首日准备：必须呈现绿灯的指标
• 主通道失败时的有序备份路径（无双重扣款）

从 IOSOR 开始

导出旧 endpoint backlog，排空到 quiet，然后在唯一所有者 URL Live 时吊销密钥。在新路径重跑 day-1 runway，并对任何排空中途事故书面保留 failover 顺序，再提高量。 割接前把 spend 证明和买家文案清洗写进同一份密封地图，财务签字后再换 Live 密钥。 队列未 quiet 前不要归档旧 endpoint，也不要切密钥。

IOSOR 要点

切密钥前先排空旧 webhook：in-flight DLR 是你仍欠的真相。清点、quiet、吊销，再重证 runway——不要为了好看的割接日历而孤儿化 finals。