Shopify 案例的核心責任是把可預期峰值轉成可預演流程。當流量高峰是年度固定事件，可靠性工作重點是提前把容量與失效路徑變成可驗證資產，臨場救火代表準備不足。

問題場景

BFCM 類型高峰會同時放大三種壓力：流量突增、資料層寫入壓力、跨服務依賴抖動。若只在活動前做單次壓測，團隊通常只能看到系統上限，無法看到恢復節奏與指揮負載。

Shopify 的做法是把容量規劃、隔離邊界與演練節奏綁成同一條年度路線。

決策機制

這個機制的價值是讓高峰風險在活動前被分批消化，而不是在活動中一次承擔。

可觀測訊號

常見陷阱

把高峰準備當成一次性專案會讓知識斷層快速累積。可靠做法是把每輪活動輸出的缺口回寫成固定資產：runbook、matrix、驗證腳本與放行門檻。這讓下一輪準備從更高基準開始，而不是重來。

下一步路由

若要落地本案例，先從 6.9 建容量模型，再在 6.22 定義高峰穩態。演練證據回寫 6.23 與 8.6。