Discord on Tarragonhttps://tarrragon.github.io/blog/backend/08-incident-response/cases/discord/Recent content in Discord on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 01 May 2026 00:00:00 +0000Discord：Gateway 容量事件與恢復節奏https://tarrragon.github.io/blog/backend/08-incident-response/cases/discord/2022-gateway-capacity-event/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/08-incident-response/cases/discord/2022-gateway-capacity-event/<p>這起案例的核心責任是把長連線流量恢復做成可分批節奏。容量事件若直接全量回復，容易觸發二次擁塞。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>判讀重點</th> <th>回寫章節</th> </tr> </thead> <tbody> <tr> <td>gateway saturation</td> <td>是否超出穩態邊界</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/steady-state-definition/" data-link-title="6.22 Steady State Definition" data-link-desc="在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化">6.22</a></td> </tr> <tr> <td>reconnect queue growth</td> <td>回復是否放大壓力</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/containment-recovery-strategy/" data-link-title="8.3 止血、降級與回復策略" data-link-desc="把短期止血與正式回復拆成可執行步驟">8.3</a></td> </tr> <tr> <td>region imbalance</td> <td>影響是否偏斜</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/customer-impact-assessment/" data-link-title="8.20 Customer Impact Assessment" data-link-desc="把受影響用戶、功能、區域、金額、SLO 與補償判斷串成影響評估模型">8.20</a></td> </tr> </tbody> </table> <h2 id="邊界判讀">邊界判讀</h2> <p>這個案例的邊界是「長連線回復節奏」不能跨過穩態容量。主要風險是全量 reconnect 直接壓垮 gateway，讓恢復動作本身成為二次事故來源。</p> <h2 id="下一步路由">下一步路由</h2> <p>先定義分批回復門檻，再在 <a href="https://tarrragon.github.io/blog/backend/08-incident-response/multi-incident-coordination/" data-link-title="8.14 Multi-incident Coordination" data-link-desc="把同時多事故的優先序、資源分配與 incident command system pool 協調變成可執行流程">8.14</a> 固化協調規則，並回寫 <a href="https://tarrragon.github.io/blog/backend/06-reliability/steady-state-definition/" data-link-title="6.22 Steady State Definition" data-link-desc="在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化">6.22</a> 的穩態門檻。</p>這起案例的核心責任是把長連線流量恢復做成可分批節奏。容量事件若直接全量回復，容易觸發二次擁塞。

判讀訊號

訊號 判讀重點 回寫章節
gateway saturation 是否超出穩態邊界 6.22
reconnect queue growth 回復是否放大壓力 8.3
region imbalance 影響是否偏斜 8.20

邊界判讀

這個案例的邊界是「長連線回復節奏」不能跨過穩態容量。主要風險是全量 reconnect 直接壓垮 gateway，讓恢復動作本身成為二次事故來源。

下一步路由

先定義分批回復門檻，再在 8.14 固化協調規則，並回寫 6.22 的穩態門檻。

]]>