流量上線後故障轉移營運手冊

流量上線後的故障轉移是營運事件，涉及金錢和客戶信任。在尋呼機響起前，請指定三位負責人：誰可以翻轉線路順序、誰監控消耗和停損線，以及誰負責線路切換期間買家所看到的一切。

IOSOR 是白標預付費服務。USD 20 資金用於試點階段；接近 USD 1,000/month 的軟性審查是無序翻轉變得昂貴的時候。先決條件：無重複扣款的備援路徑、上線前故障轉移閘門、部分故障轉移發送無重複扣款。這與 規模化簡訊路由與營運 不同 — 在這裡，我們在實時切換中擁有人員和權力。

尋呼機響起前的角色

在情況平靜時寫下角色。指定一位線路排序負責人、一位錢包上限的消耗負責人，以及一位客戶介面和 webhook 內容的狀態負責人。在小型團隊中，這些職責可能會重疊；但請將它們在書面上分開，以免凌晨 02:00 的事件需要臨時創建組織架構。

誰可以在大量流量下重新排序線路

只有指定的線路排序負責人（或預先委派的備用人員）可以更改實時序列：更新書面路徑，如果時間允許，在試點金鑰下測試新的備用線路，然後切換 — 而不是分散到每條線路或在聊天中創建路徑。

每次在大量流量下重新排序都是一個審計事件：誰、何時、通道、為何。資金身份仍遵循 部分故障轉移發送無重複扣款。如果上線閘門從未變綠，請先拉下流量 — 不要在生產環境中修復順序。

消耗監控和錢包停損線

故障轉移風暴比穩定的主要線路更快地消耗預付費。消耗負責人監控 正式流量前的錢包停損線 和 預付費支出控制。停損線在試點錢包清空前暫停或減少流量 — 而不是在軟性 USD 1,000/month 審查已經造成損失之後。

在事件中導出消耗數據：切換的單位、結算與釋放、受影響的通道。沒有匹配客戶流量的消耗是金錢錯誤（重複結算或浪費），而不是路由噪音。

切換期間的客戶狀態所有權

買家看到一個誠實的 IOSOR 軌跡：已接受、待處理、已送達、失敗、需要注意。狀態負責人更新內容和支援巨集，以便飛行中的跳轉不會看起來像重複發送或虛構的「已送達」。營運日誌可以命名履行線路；客戶介面絕不能。延遲 ≠ 自動故障轉移；路由規模仍歸 SMS 營運所有。在這裡，一個指定的人負責客戶在線路移動時所閱讀的內容。

買家/營運上線流量檢查清單

1. 線路排序、消耗和狀態負責人是否在上線流量前指定？
2. 只有指定的負責人可以重新排序 — 附帶工單和導出？
3. 錢包停損線和支出上限是否在事件中啟用？
4. 客戶狀態是否為白標，切換期間沒有品牌洩漏？
5. 在流量高峰前，飛行中的資金身份是否已證明（每次意圖扣款一次）？
6. 之後：帳本導出、時間軸、恢復主要順序的決定？

從 IOSOR 開始

呼叫器響之前點名三位負責人：誰可重排軌道、誰看燃燒與錢包停線、誰擁有買家看到的狀態文句。量已經活著時排練一次切換：強制 hop、確認一筆 debit、確認停線撐得住、確認措辭。量場上沒名字的手冊是昂貴呼叫器。

IOSOR 要點

量場手冊是具名負責人和停線，不是延遲公式。

要做：寫下量已是 Live 時誰可翻軌道、誰跟買家說話。

不要：讓第一聲呼叫發明軌道次序，或把第二筆 debit 藏在「我們切過去了」後面。