突發流量按可預測性分成兩類。可預期的突發（行銷活動、新聞發佈）可以事前準備容量；不可預期的突發（病毒傳播、error storm）只能靠架構設計吸收衝擊。

可預期突發

事前知道流量會增加，有時間準備。

來源流量倍率持續時間特徵
行銷活動（促銷、限時折扣）5-50x數小時～數天流量集中在活動開始的前幾分鐘
新聞曝光（媒體報導、社群爆紅）10-100x數小時不可控的流量曲線、峰值在發佈後 1-2 小時
定時推播（每日報表、週報）2-10x分鐘級短暫但可精確預測時間
新版本推送（app store 更新）3-10x數天（逐漸擴散）流量緩慢上升、峰值在推送後 24-48 小時

可預期突發的應對核心是容量預備 — 活動前擴容、活動後縮回。

預備清單

項目做什麼何時做
容量估算歷史峰值 × 安全係數（1.5-2x）活動前 1 週
擴容加實例 / 加資源 / 預熱 cache活動前 1 天
降級預案設定動態取樣的觸發閾值活動前 1 天
壓力測試模擬預期流量打 staging活動前 3 天
值班安排值班人員監控 dashboard活動期間

不可預期突發

事前不知道流量會增加，只能靠架構設計吸收。

來源流量倍率持續時間特徵
病毒傳播（社群分享爆量）10-1000x數小時完全無法預測、可能超過任何預備容量
DDoS 攻擊100-10000x不定惡意流量、需要 WAF / CDN 擋在前面
Error storm（app bug 觸發大量 error）依 bug 影響範圍直到 hotfix每個受影響的使用者都在送 error 事件
外部依賴復原（積壓請求一次湧入）2-5x分鐘級依賴恢復後積壓的 retry 一起到達

不可預期突發的應對核心是降級 — 系統在超載時自動犧牲非核心功能，保住核心功能。

監控系統的 error storm

Error storm 是監控系統特有的突發場景：被監控的 app 出了 bug，每個受影響的使用者都在送 error 事件。如果有 10 萬使用者同時遇到同一個 bug，collector 瞬間收到 10 萬筆 error 事件。

Error storm 的矛盾：error 事件是 debug 最需要的資料，但 storm 時的大量 error 可能打垮 collector。處理策略是保留前 N 筆完整 error（含 stack trace）、後續的 error 只計數不存原始資料。第一筆 error 的 stack trace 足夠 debug，後續的 10 萬筆只是確認影響範圍。

下一步路由