今天分享 MCP webhook 被短時大量請求（Spike）後，系統上會出現的影響與觀察到的指標。

攻擊後你會看到的狀況

以下為常見、可直接量化的異常指標與現象，方便快速判讀狀態是否已惡化。

1. 應用層表現惡化

• 平均/尾端延遲暴升：p50、p95、p99 明顯上升（例如從幾百毫秒飆到秒級或以上）。
• 請求失敗率上升：5xx/4xx 數量增加，client 看到錯誤或超時。
• 連線/執行佇列長度變長：worker pool 或 thread 池飽和，新的請求被排隊或拒絕。

2. 主機與資源耗盡

• CPU 飆高與頻繁 context-switch，導致延遲進一步惡化。
• 記憶體使用量上升或 OOM（若有記憶體洩漏或大量暫存）。
• 磁碟 I/O 與日誌增多，磁碟空間快速被填滿（尤其大量日誌/暫存）。
• 網路頻寬接近飽和，影響其他服務或上游/下游通訊。

3. 下游服務 / 成本面衝擊

• n8n / worker 任務堆積：排程任務被大量創建，造成 backlog 與重試風暴（retry loop）。
• 第三方 API 或付費服務消耗暴增（如 LLM、外部 SaaS），可能導致意外高額帳單。
• 資料庫負載上升：大量寫取／查詢造成鎖、延遲或連線耗盡。

4. 使用者與業務影響

• 真實使用者體驗惡化：頁面/功能失敗、操作延遲。
• 服務可用性下降：部分功能不可用或整體回應不穩定。
• 合約或 SLA 違約風險：若影響 production，可能觸發 SLA penalties。

典型監控面板要看哪些數值

• 系統：CPU%、Memory%、Disk%（使用率）、Network I/O。
• 應用：Requests/sec、p95 / p99 latency、錯誤率(5xx)、活躍連線數、thread/worker 利用率。
• 下游：task queue 長度、外部 API 呼叫數/分鐘、DB 連線使用率。
• 成本：第三方 API 使用次數 / token /花費速率（若可量化）。

緊急處理要點

1. 啟動 kill-switch（快速封鎖測試來源 IP 或關閉測試入口）。
2. 調低入口負載：啟用或加嚴 rate limit / 暫時返回 429。
3. 暫停高成本下游呼叫（例如暫時禁用會花錢的外部 API）。
4. 清查並調整 worker queue：停止重試、排程消化策略、擴容或暫停新任務入列。
5. 把重要指標通知 SRE / On-call（CPU、錯誤率、queue 長度）。

實測結果截圖

在這次模擬攻擊中，我使用 k6 對 MCP Webhook 發送突發流量（Spike），最高同時 80 個虛擬使用者 (VUs)，持續約三分鐘。以下為實測輸出畫面：

從結果可以看到：

• p95 延遲 = 6.15 秒（已遠超預期門檻 5 秒），代表尾端延遲暴增。
• 平均延遲約 3.19 秒，相較正常情況（毫秒級）明顯惡化。
• 最大延遲達 11.56 秒，證明在高併發下系統明顯被拖慢。
• 請求失敗率雖為 0%，但這是因為所有請求最終仍成功回應，不代表服務品質可接受。

這與我們前面提到的「延遲上升、佇列變長」現象完全吻合。即使沒有明顯錯誤碼，使用者體驗也會因延遲過長而受到嚴重影響。

總結

1. 重點觀察：延遲、錯誤率、隊列長度 — 這三項通常最先暴露系統被拉垮的程度。
2. 先保護成本與下游：若下游會造成金流上升（付費 API），優先切斷或降級這些呼叫。
3. 事後措施：加速落實 rate limiting、API 認證、工具白名單與 queue 限制，避免未授權或意外流量造成實際損失。