平台停機應變清單：由事故分級、內外通報到服務復原的處理流程

事故分級：建立客觀量化的判定門檻

分級制度最忌諱語意含糊。當值班工程師在深夜或假日時段被告警喚醒，大腦認知負荷極高，若應變手冊僅以「重大影響」或「一般異常」等主觀詞彙定義，現場極易出現判斷失誤，導致該升級的事故遭到延誤，或輕微波動過度動員全體團隊。一套具備實操性的分級機制，必須將量化技術指標（如錯誤率、請求延遲、流量跌幅）與業務影響維度（核心交易中斷、資安洩漏風險、法規違約）進行多維綁定。

動態升降級原則與決策防線

在故障處置初期，資訊往往高度破碎。標準應變原則要求「從嚴定級、就高不就低」：在無法確定具體波及範圍時，應優先按照高等級（如 SEV1）啟動應變機制。隨著排查深入，若確認問題僅局限於非核心子服務，則由事件總指揮官在作戰室統一下達降級指令，並記錄降級依據；反之，若次要異常在 30 分鐘內持續惡化並侵蝕核心系統資源，必須立即無條件升級，拉入更高層級的技術資源。

指揮鏈體系：明確角色與權責邊界

重大故障現場最忌多頭指揮或全員扎堆分析日誌而無人統籌局勢。借鑑 ICS（事故指揮體系）架構，應變團隊必須在進入作戰室的第一時間明確以下四大核心角色：

• 事件總指揮官（Incident Commander, IC）：全場最高決策者，負責掌控處置節奏、維持通訊紀律、評估各項技術處置方案的風險，並握有最終回滾與系統熔斷的拍板權限。IC 本人不應親自編寫代碼或深陷日誌排查，以維持全域視角。
• 技術處置主管（Tech Lead / Ops Lead）：直接帶領基礎設施、DBA、後端與安全團隊進行故障隔離、根因溯源與修復代碼實施，並持續向 IC 提報技術評估結果。
• 溝通協調官（Communications Lead / Scribe）：負責在應變作戰室內即時記錄關鍵時間節點（決策、動作、指標變化），並按約定時限草擬內部 SITREP 報告與外部狀態頁更新文案，經 IC 審核後統一發布。
• 客服與前線聯絡官（Liaison Lead）：負責將作戰室確認的事實轉化為前線客服的統一話術口徑，彙整前線回饋的用戶異常特徵提供給技術組，並向管理階層、法務及公關團隊同步最新狀態。

內部通報：標準化資訊流與作戰室運作紀律

內部通報的核心目標在於建立單一事實來源（Single Source of Truth），徹底杜絕各部門在不同即時通訊群組內胡亂猜測或私下追問工程人員，讓處置團隊能百分之百聚焦於止血修復。所有對內通報應遵循高度結構化的 SITREP（Situation Report 情況報告）格式。

線上緊急作戰室運作規範

當 SEV1 或 SEV2 事故觸發時，專屬的虛擬作戰室（如專用視訊會議及獨立聊天頻道 #incident-warroom）應在 3 分鐘內自動就緒。作戰室應遵守三項基本紀律：

1. 發言管制與單軌協調：除 IC、Tech Lead 與當前執行動作的工程師外，其餘人員保持靜音，避免多嘴發問打斷思路。
2. 操作複誦與確認（Three-Way Communication）：任何對生產環境（Production）執行的指令，工程師執行前必須在作戰室清晰口頭通報：「我現在準備執行 [操作 A]，預期影響 [B]」，獲 IC 同意後方可按下執行鍵，執行完畢後立即回報結果。
3. 跨時區交接協議：重大事故若處置時間超過 4 小時，IC 必須啟動疲勞輪換機制，以結構化文檔進行 15 分鐘的交接對齊，嚴防因過度疲勞導致操作誤失。

對外通報：狀態頁、客服口徑與合規審核

對外溝通直接決定了公眾輿論與品牌商譽。事故發生時，用戶最痛恨的並非偶發故障，而是官方的傲慢、隱瞞或長時間沉默。對外溝通必須建立在「透明、客觀、可預期」的原則之上，並維持嚴格的授權審批機制。

公開狀態頁（Status Page）維運準則

狀態頁必須具備架構獨立性，強烈建議託管於第三方獨立雲服務商，以確保在主站基礎設施完全癱瘓時仍能正常存取對外發布公告。狀態頁公告生命週期應遵循以下節奏：

• 調查中（Investigating）：故障確認後 15 分鐘內發布。重點是承認已知問題，告知用戶團隊正在全力搶修，切忌等待根因徹底查明才發布首則公告。
• 已識別（Identified）：確認問題源頭後發布，簡要說明受影響範疇，並提供預估下次更新時間或預計恢復區間（若具備高置信度）。
• 監控驗證中（Monitoring）：修復措施已部署，系統指標正在回穩，提醒用戶部分功能可能存在短暫延遲。
• 已復原（Resolved）：指標已連續 30 分鐘正常，宣告事件結束，並承諾後續將提供正式覆盤摘要。

前線客服話術矩陣（Can Say vs Cannot Say）

客服與社群前線團隊必須在事故發布 15 分鐘內拿到統一應對口徑，嚴禁客服人員憑個人猜測回答用戶諮詢：

法規申報與免責邊界

若事故判定涉及個人資料外洩、金融交易遺失或關鍵基礎設施中斷，必須即刻觸發合規通報流程。各主要司法管轄區（例如香港個人資料私隱專員公署、歐盟 GDPR、各國金融監管機構）對重大資安事故或資料外洩均設有嚴格的強制通報時限（例如部分法規要求於知悉後 72 小時內通報，金融領域則可能要求更短時限）。法務與合規團隊必須在 SEV1 事故觸發後 30 分鐘內介入評估，所有涉及責任認定、資料安全聲明與賠償承諾之對外文件，必須經法務會簽審批後方可發布。

技術復原：優先止血與時間盒決策模型

技術處置的核心邏輯是「先止血、後排查、再治本」。在重大停機現場，工程師往往有一種追查代碼深層 Root Cause 的技術本能，但 IC 的責任是強行約束團隊，優先執行能最快恢復業務可用性的手段，而非在生產環境就地 Debug。

階梯式止血手段

1. 流量調度與隔離（Traffic Rerouting）：若為多可用區（Multi-AZ）或多區域架構，第一時間將流量自故障節點或異常機房完全剔除；啟用 CDN / WAF 限流規則阻斷惡意或異常激增之流量。
2. 業務功能降級（Graceful Degradation）：關閉高耗能、非核心業務模組（如個性化推薦、即時排行榜、繁重報表匯出），將有限的計算與資料庫 IOPS 資源全數保留給登入與交易主幹。
3. 快取兜底與靜態化（Stale Cache Fallback）：針對讀取密集型系統，強制啟用過期快取服務（Serve Stale Content），阻斷流量直接擊穿至後端資料庫。
4. 功能開關切換（Feature Flag / Kill Switch）：若系統配備特性開關，立即關閉最近 24 小時內開啟的新功能特性。

時間盒（Timebox）強制回滾機制

許多重大停機事件之所以持續數小時，往往是因為團隊誤判了「線上熱修復（Hotfix）」的難度。應變清單中必須設定嚴格的時間盒：

15 分鐘強制回滾原則：若事故發生在最新版本發布、配置變更或架構遷移後的 2 小時內，且技術團隊在介入後的 15 分鐘內 無法定位明確、低風險且可在 5 分鐘內部署的熱修復方案，IC 必須下達強制指令：立即全量回滾至上一已知穩定版本。禁止在未明原因的情況下於生產環境反覆嘗試修補。

服務復原：防範次生災害與驗證放行

技術補丁部署或回滾完成並不等同於服務已完全復原。盲目、瞬間放開全量流量，極易引發嚴重的「驚群效應（Thundering Herd）」與資料庫雪崩，導致系統二次當機。

有序放行與系統預熱（Cold-to-Warm Recovery）

• 快取預熱（Cache Warming）：在流量重新切入前，由腳本對核心高頻熱點資料進行快取預加載，避免資料庫在開閘瞬間被巨大讀取流量壓垮。
• 梯度引流（Canary Traffic Shifting）：以 5% → 20% → 50% → 100% 的節奏逐步開放外部流量，每階梯停留觀察 5–10 分鐘，密切監控 CPU、連線池與佇列長度。
• 非同步任務削峰（Queue Throttling）：針對停機期間堆積的數十萬筆非同步任務、推播通知與死信佇列（DLQ），嚴格限制消費速率，採平滑速率消費，不可與線上即時交易競爭資源。

資料一致性校驗與補償

在宣告復原前，必須執行嚴格的後台資料審計：

• 啟動分散式事務對帳腳本，排查停機瞬間產生的「懸掛事務（Hanging Transactions）」與半完成訂單。
• 針對支付成功但業務未履約之訂單，執行自動化補發貨或退款補償邏輯。
• 合成監控探針（Synthetic Monitoring）端到端主流程測試連續 30 分鐘無報警，核心 API P99 延遲回歸基線水位。

無責覆盤：將故障轉化為架構韌性

任何未轉化為架構防禦措施的停機，都是對企業資源與商譽的純粹浪費。事故覆盤（Post-mortem）必須維持堅定不移的無責文化（Blameless Post-mortem）。無責覆盤的根本前提是：假設所有工程師在當時的情境與資訊掌握度下，均做出了其所能做出的最佳決策；系統之所以出事，是因為基礎設施、防禦機制與組織流程允許了該錯誤的發生與擴散。

平台停機應變檢查清單（Checklist）

以下檢查表供團隊在不同應變階段逐項打勾確認，建議列印成實體卡片並置於應變控制台，或配置於離線知識庫中：

常見問題與實務陷阱（FAQ）