实时流量下的故障转移操作手册

实时流量后的故障转移是一项涉及资金和客户信任的运营事件。在寻呼机响起之前，明确三位负责人：谁可以调整通道顺序，谁监控消耗和止损线，以及谁在通道切换期间负责买家所看到的内容。

IOSOR 是白标预付费平台。USD 20 为试点下限提供资金；接近 USD 1,000/month 的软性审查是无序切换变得昂贵的时候。先决条件：主通道失败时的有序备份路径（无双重扣款），Live 徽章前的故障转移闸门，部分故障转移发送无双重收费。这与规模化短信路由与运营不同——这里我们拥有实时切换中的人员和权限。

寻呼机响起前的角色

在情况平静时明确角色。指定一个通道顺序负责人，一个钱包上限的消耗负责人，以及一个负责客户 UI 和 webhook 文本的状态负责人。在小型团队中，职责可能重叠；但在书面上应保持分离，以防凌晨 02:00 的事件临时发明组织结构图。

谁可以在实时流量下重新排序通道

只有指定的通道顺序负责人（或预先委派的备份）可以更改实时序列：更新书面路径，如果时间允许，在试点密钥下测试新备份，然后切换——而不是分散到每个通道或在聊天中临时创建路径。

实时流量下的每一次重新排序都是一个审计事件：谁、何时、何地、为何。资金身份仍然遵循部分故障转移发送无双重收费。如果 Live 闸门从未变为绿色，请首先撤回流量——不要在生产环境中修复顺序。

消耗监控与钱包止损线

故障转移风暴比稳定的主通道更快地消耗预付费。消耗负责人监控生产流量前的钱包止损线和预付费支出控制。止损线在试点钱包清空之前暂停或削减——而不是在软性 USD 1,000/month 审查已经造成损失之后。

在事件中导出消耗数据：切换的单位、结算与释放、受影响的通道。没有匹配客户流量的消耗是资金错误（双重结算或滥发），而不是路由噪音。

切换期间的客户状态所有权

买家看到的是一个诚实的 IOSOR 轨迹：已接受、待处理、已送达、失败、需要注意。状态负责人更新文本和支持宏，以便飞行中的跳跃不会看起来像重复发送或虚假的“已送达”。运营日志可以命名履行通道；客户界面绝不能。延迟滞后 ≠ 自动故障转移；路由规模仍由短信运营负责。这里，一个指定的人负责在通道移动时客户所阅读的内容。

实时流量下的买家/运营检查清单

1. 在实时流量前是否已指定通道顺序、消耗和状态负责人？
2. 是否只有指定的负责人可以重新排序——并附带工单和导出？
3. 事件中是否激活了钱包止损线和支出上限？
4. 切换期间客户状态是否为白标，无品牌泄露？
5. 在流量高峰前是否已证明飞行中资金身份（每次意图一次扣款）？
6. 之后：账本导出、时间线、恢复主通道顺序的决定？

从 IOSOR 开始

呼叫器响之前点名三位负责人：谁可重排轨道、谁看燃烧与钱包停线、谁拥有买家看到的状态文句。量已经活着时排练一次切换：强制 hop、确认一笔 debit、确认停线撑得住、确认措辞。量场上没名字的手册是昂贵呼叫器。

IOSOR 要点

量场手册是具名负责人和停线，不是时延公式。

要做：写下量已是 Live 时谁可翻轨道、谁跟买家说话。

不要：让第一声呼叫发明轨道次序，或把第二笔 debit 藏在「我们切过去了」后面。