INC-2026-0423

網格交易系統限速異常導致 hedge 延遲

SEV-2 已結案持續 37 分鐘偵測時間 04/23 · 02:18 負責人 KW

摘要

新版本 cfg-grid-v3.2 在 per-strategy rate-limit 欄位填入 debug 用的 6 req/min，覆蓋了原本繼承全域的 60 req/min。網格策略 GRID-V3 在亞洲早盤觸發限速，新下單被排隊，hedge leg 延遲最高 47 秒，造成 3.2 BTC 短暫單邊敞口（仍在風控容忍內）。 revert 設定 + 重啟策略 worker 後恢復，無資金損失、無強平。

時間軸

02:14

設定 cfg-grid-v3.2 透過標準 rollout pipeline 推到 production，包含新加的 per-strategy rate-limit 欄位。

02:18

影響開始。GRID-V3 的下單請求達到 6 req/min 上限後被 broker 端 throttle， hedge leg 開始排隊；p95 下單延遲從 0.4s 飆到 38s。

02:19

告警觸發：hedge_lag_p95 > 30s 持續 60s。 on-call（KW）收到 Telegram 通知。

02:24

初判懷疑 broker 端 API 異常，先打 broker support 線上客服回報；同時 rollback 兩個前一日的策略 code deploy，無效果。

02:36

JL 加入排錯，從 broker dashboard 看到請求數遠低於帳號上限，判斷瓶頸不在 broker 端；轉查內部 rate-limit 設定，發現 cfg-grid-v3.2 寫的是 6 req/min。

02:48

已緩解。revert cfg-grid-v3.2、重啟策略 worker； hedge_lag_p95 三分鐘內回到 4s 以下。

02:51

監控連續 5 分鐘綠燈，宣告結案；策略 dashboard 標註本次事件區間。

根本原因

PR #3217 為每個策略加上獨立的 rate-limit 上限，方便未來細粒度控管。本意是讓新欄位 per_strategy_rpm 預設繼承全域值（60），但開發時為了在 local 測 throttle 行為，把預設值硬寫成 6 後忘了改回來。

config linter 只檢查欄位型別，沒有 magnitude（合理範圍）檢查，所以 6 req/min 過了 CI。加上設定 rollout 跟 code deploy 走不同 pipeline，on-call 第一直覺去 rollback code deploy 其實沒有效果，多花了 12 分鐘繞遠路。

infra/config/strategies.yaml   rate_limit:
     global_rpm: 60
     per_strategy:
-      GRID-V3: { rpm: 60 }
+      GRID-V3: { rpm: 6 }   # debug 用值，勿上 prod
       MR-V1:   { rpm: 30 }

影響評估

失敗 / 延遲下單	~340 筆
hedge_lag 峰值	47 秒
受影響策略	1（GRID-V3）
單邊敞口峰值	3.2 BTC
實質損益	無 — 未觸發強平 / 停損

後續行動

KW revert cfg-grid-v3.2、重啟策略 worker（事件當下完成） 04/23

JL config linter 加 magnitude check：per_strategy.rpm < 10 觸發 CI 警告 04/30

KW 策略 dashboard 加「目前 rate-limit / 實際使用率」即時顯示 05/07

TM rate-limit 設定改用 canary：先推一個策略 10 分鐘無異常再全域 rollout 05/14