FSTS Cutover Runbook
Stage 6 Final 版。目標是把 Cutover 從「靠經驗」提升成「可排演、可簽核、可回復」的正式作戰手冊。完整版見 原 Runbook。
文件定位
1
| 項目 | 內容 |
|---|
| 適用場景 | 舊複委託系統切換至新一代開放平台 |
| 切換型態 | 以分階段平行驗證後的一次主切換為原則；必要時採市場別或通路別滾動切換 |
| 關鍵成功條件 | 資料差異在門檻內、FIX/API/銀行/保管行聯測通過、日切 Runbook 演練通過、關鍵窗口 24×7 待命 |
治理原則
2
- 切換前至少完成三輪試轉：冷試轉 → 熱試轉 → 準正式試轉
- 主切換前需完成一輪完整平行日切，由交易 / 清算 / 客服 / 財會共同簽認
- 回復機制必須先於切換腳本完成；若回退腳本未驗證，主切換不得啟動
- 所有 Go/No-Go 會議均需保存會議紀錄、門檻檢查表、責任人簽名
切換階段矩陣
3
| 階段 | 目標 | 主要作業 | 進入條件 | 退出條件 |
|---|
| T-30 ~ T-7 | 準備與凍結 | 參數 / 版本凍結、最終演練、名單確認 | SIT/UAT/平行測試完成 | 正式切換包簽核完成 |
| T-3 ~ T-1 | 資料封存與預檢 | 舊系統資料快照、帳務對帳、切換環境驗證 | 來源環境穩定 | 差異在可接受門檻內 |
| T Day | 主切換 | 停收單、最終抽檔、資料轉換、介接切換、Smoke Test | Go 決策通過 | 生產驗證通過 |
| T+1 ~ T+5 | 加強監控 | 日內 / 日終加強監控、缺陷快修、差異比對 | 主切換成功 | 營運穩定指標達標 |
| T+6 之後 | 穩定營運 | 轉入一般維運與保固 | 指揮中心解除 | 項目結案 |
指揮體系與責任
4
| 角色 | 責任 | Go/No-Go 表決權 |
|---|
| Executive Sponsor | 最終風險承擔 / 高層決策 | ✅ |
| Cutover Commander | 總協調 / 時程控管 / 異常升級 | ✅ |
| DBA Lead | 備份 / 還原 / DDL-DML / 效能監控 | ✅ |
| Interface Lead | FIX / API / FTP / 銀行 / 保管行切換 | ✅ |
| App Lead | 應用發布 / 參數切換 / Smoke Test | ✅ |
| QA Lead | 測試證據 / 缺陷清單 / 驗證門檻 | ❌ |
| Business Sign-off Lead | 交易 / 清算 / 客服 / 財會簽認 | ✅ |
主切換 Runbook（T Day 核心 10 步）
5
| 步驟 | 動作 | 負責 | 時點 |
|---|
| C-01 | 宣告切換口開始（全員到位、會議橋） | Commander | T Day 18:00 |
| C-02 | 停收新委託與通路封盤（前台 / API / 分公司 / Web） | App Lead / 業務 | T Day 18:10 |
| C-03 | FIX / API 最終在途訊息清空（確認 SeqNum、佇列清空） | Interface Lead | T Day 18:30 |
| C-04 | 舊系統最終資料快照（客戶 / 商品 / 庫存 / 餘額 / 未交割 / 未了委託） | DBA Lead | T Day 19:00 |
| C-05 | 執行資料轉換與載入新系統 staging + 正式表 | DBA / Migration Lead | T Day 19:15–21:00 |
| C-06 | 執行差異比對與簽認（客戶數 / 庫存 / 現金 / 未交割 / 公司行動） | QA / Business | T Day 21:00–22:00 |
| C-07 | 切換對外路由（FIX Session / 新 API Gateway / SFTP 端點） | Interface Lead | T Day 22:00 |
| C-08 | Smoke Test（查詢 / 下單 / 撤單 / 成交模擬 / 報表 / 監控） | QA / 業務 / App | T Day 22:10–23:00 |
| C-09 | Go / No-Go 決策會議（依門檻表決定是否開放生產） | 全體決策角色 | T Day 23:00 |
| C-10 | 開放新系統營運（對內宣告完成 + 啟動加強監控） | Commander | T Day 23:15 |
Go / No-Go 門檻
6
| 檢項目 | 門檻 | 不通過處理 |
|---|
| 資料差異 | 核心主檔 / 庫存 / 現金 / 未交割 / 公司行動皆在已簽准門檻內 | 停在 T Day，改執行回復腳本 |
| FIX / API / 銀行 / 保管行 | 關鍵介接皆通過連線與樣本交易驗證 | 由 Interface Lead 決定是否延期 |
| 日切批次 | 最後一次演練總時長在正式窗口內且無 Blocker | 重新排演並調整窗口 |
| Smoke Test | 核心交易 / 查詢 / 清算 / 報表 / 監控全部通過 | No-Go |
| 回復能力 | 完整備份 / 還原演練 / 資料回補機制皆已驗證 | No-Go |
回復策略（Rollback Matrix）
7
| 場景 | 觸發條件 | 回復方式 | 責任人 | 對外溝通 |
|---|
| 資料差異超門檻 | 核心帳務 / 庫存差異不可接受 | 停止 Go；空新系統增量，還原舊系統接單 | DBA Lead + Commander | 內部緊急通告 |
| FIX 無法穩定連線 | 關鍵上手連線失敗或回報異常 | 切回舊路由與舊 Session | Interface Lead | 通知交易與客服 |
| 日切無法完成 | 清算 / 帳務 / 報表在窗口內無法完成 | 恢復舊日切，延期切換 | App Lead + DBA | 通知管理階層 |
| 高風險缺陷 | 下單 / 撤單 / 成交核心流程 Blocker | 立即回復，重開舊系統通路 | Commander | 對內公告 + 客服話術 |
T+1 ~ T+5 加強監控
8
- 交易時段每 30 分鐘檢查 FIX Session / API 成功率 / 回報延遲 / 當日成交筆數 / 與舊系統基線
- 日終比對：現金 / 庫存 / 交割 / 損益 / 公司行動 / 會計介接 / 監理報表
- 所有 P1/P2 缺陷須於 24 小時內完成根因分類與修復計畫
- 維持戰情室與單一決策口，避免業務 / 維運各自處置造成風險擴散
切換證據最低要求
9
| 項目 | 內容 |
|---|
| 必要附件 | 切換腳本版控編號 / 資料差異報表 / Smoke Test 結果 / Go/No-Go 紀錄 / 回復腳本驗證結果 |
| 日誌保留 | FIX Log / API Access Log / 批次 Run Log / DB 變更單 / 參數異動紀錄 |
| 簽核 | 交易 / 清算 / 客服 / 財會 / 資訊 / PMO 共同簽認 |
專案負責人 Review 結論
10
真正成功的 Cutover，不是『上線當晚沒出事』，而是『切換前知道風險、切換中知道決策點、切換後知道如何證明結果正確』。
本 Runbook 已把主切換從單純技術活動提升為跨交易 / 清算 / 客服 / 財會 / 維運的共同指揮框架，可直接作為正式呈核與演練母版。
補充資訊
(未來 ingest 新來源會在此追加段落)
參考資料