Error-Storm on Tarragonhttps://tarrragon.github.io/blog/tags/error-storm/Recent content in Error-Storm on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Sat, 20 Jun 2026 00:00:00 +0000突發流量的分類https://tarrragon.github.io/blog/devops/07-burst-traffic/burst-classification/Sat, 20 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/devops/07-burst-traffic/burst-classification/<p>突發流量按可預測性分成兩類。可預期的突發（行銷活動、新聞發佈）可以事前準備容量；不可預期的突發（病毒傳播、error storm）只能靠架構設計吸收衝擊。</p> <h2 id="可預期突發">可預期突發</h2> <p>事前知道流量會增加，有時間準備。</p> <table> <thead> <tr> <th>來源</th> <th>流量倍率</th> <th>持續時間</th> <th>特徵</th> </tr> </thead> <tbody> <tr> <td>行銷活動（促銷、限時折扣）</td> <td>5-50x</td> <td>數小時～數天</td> <td>流量集中在活動開始的前幾分鐘</td> </tr> <tr> <td>新聞曝光（媒體報導、社群爆紅）</td> <td>10-100x</td> <td>數小時</td> <td>不可控的流量曲線、峰值在發佈後 1-2 小時</td> </tr> <tr> <td>定時推播（每日報表、週報）</td> <td>2-10x</td> <td>分鐘級</td> <td>短暫但可精確預測時間</td> </tr> <tr> <td>新版本推送（app store 更新）</td> <td>3-10x</td> <td>數天（逐漸擴散）</td> <td>流量緩慢上升、峰值在推送後 24-48 小時</td> </tr> </tbody> </table> <p>可預期突發的應對核心是<strong>容量預備</strong> — 活動前擴容、活動後縮回。</p> <h3 id="預備清單">預備清單</h3> <table> <thead> <tr> <th>項目</th> <th>做什麼</th> <th>何時做</th> </tr> </thead> <tbody> <tr> <td>容量估算</td> <td>歷史峰值 × 安全係數（1.5-2x）</td> <td>活動前 1 週</td> </tr> <tr> <td>擴容</td> <td>加實例 / 加資源 / 預熱 cache</td> <td>活動前 1 天</td> </tr> <tr> <td>降級預案</td> <td>設定動態取樣的觸發閾值</td> <td>活動前 1 天</td> </tr> <tr> <td>壓力測試</td> <td>模擬預期流量打 staging</td> <td>活動前 3 天</td> </tr> <tr> <td>值班</td> <td>安排值班人員監控 dashboard</td> <td>活動期間</td> </tr> </tbody> </table> <h2 id="不可預期突發">不可預期突發</h2> <p>事前不知道流量會增加，只能靠架構設計吸收。</p> <table> <thead> <tr> <th>來源</th> <th>流量倍率</th> <th>持續時間</th> <th>特徵</th> </tr> </thead> <tbody> <tr> <td>病毒傳播（社群分享爆量）</td> <td>10-1000x</td> <td>數小時</td> <td>完全無法預測、可能超過任何預備容量</td> </tr> <tr> <td>DDoS 攻擊</td> <td>100-10000x</td> <td>不定</td> <td>惡意流量、需要 WAF / CDN 擋在前面</td> </tr> <tr> <td>Error storm（app bug 觸發大量 error）</td> <td>依 bug 影響範圍</td> <td>直到 hotfix</td> <td>每個受影響的使用者都在送 error 事件</td> </tr> <tr> <td>外部依賴復原（積壓請求一次湧入）</td> <td>2-5x</td> <td>分鐘級</td> <td>依賴恢復後積壓的 retry 一起到達</td> </tr> </tbody> </table> <p>不可預期突發的應對核心是<strong>降級</strong> — 系統在超載時自動犧牲非核心功能，保住核心功能。</p> <h3 id="監控系統的-error-storm">監控系統的 error storm</h3> <p>Error storm 是監控系統特有的突發場景：被監控的 app 出了 bug，每個受影響的使用者都在送 error 事件。如果有 10 萬使用者同時遇到同一個 bug，collector 瞬間收到 10 萬筆 error 事件。</p> <p>Error storm 的矛盾：error 事件是 debug 最需要的資料，但 storm 時的大量 error 可能打垮 collector。處理策略是<strong>保留前 N 筆完整 error（含 stack trace）、後續的 error 只計數不存原始資料</strong>。第一筆 error 的 stack trace 足夠 debug，後續的 10 萬筆只是確認影響範圍。</p> <h2 id="下一步路由">下一步路由</h2> <ul> <li>突發時的降級策略 → <a href="https://tarrragon.github.io/blog/devops/07-burst-traffic/degradation-strategy/" data-link-title="降級策略" data-link-desc="系統超載時犧牲什麼保住什麼 — 動態取樣、事件優先級、功能降級、聚合前移四種策略">降級策略</a></li> <li>Queue 做 burst 緩衝 → <a href="https://tarrragon.github.io/blog/devops/07-burst-traffic/queue-buffering/" data-link-title="Queue 緩衝" data-link-desc="在 ingestion 和 processing 之間加 message queue 做 burst 緩衝 — Kafka / NATS / Redis Streams 的選型和引入條件">Queue 緩衝</a></li> <li>不同規模的應對方案 → <a href="https://tarrragon.github.io/blog/devops/07-burst-traffic/scale-tier-response/" data-link-title="規模分級應對表" data-link-desc="自用級 → 中型 → 大型 → 商業網站級的四級應對方案 — 每級的觸發條件、架構組成和成本">規模分級應對表</a></li> </ul>突發流量按可預測性分成兩類。可預期的突發（行銷活動、新聞發佈）可以事前準備容量；不可預期的突發（病毒傳播、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 萬筆只是確認影響範圍。

下一步路由

]]>