Atlassian事故偵測改用Flink，延遲降至10秒內
CNCF Blog（Member Post，Deepak Biswas）· 2026-09-30
Atlassian 把自動事故偵測平台 AutoHOT 的資料管線，從約 90 台虛擬機加共用佇列的舊架構，換成單一 Apache Flink 作業跑在 Kubernetes 上，事件到指標的延遲從 40 秒以上降到 10 秒以內。作者是該公司中央監控與災難復原團隊的資深工程經理，文中公開了成本、召回率與失敗案例的實際數字。
原本的問題
舊系統的事件到指標延遲「好的時候也超過 40 秒」，靠約 90 台 VM 支撐，年成本約 $120K 到 $230K。更麻煩的是共用佇列：外部租戶的消費落後曾造成兩次事故。
另一個正確性缺口是「沉默」：資料庫 shard 整個掛掉時，沒有人載入頁面，也就沒有事件，偵測器看到的是一片平靜。新設計的目標因此包含獨立的消費路徑、重放時不重複計數（idempotent 寫入），以及成本跟事件量成正比而非跟接入的功能數成正比。
採用的方法
第一個決定是在 Kafka 匯流排層過濾，而不是在 Flink 作業內過濾。一份 770 行的 YAML 訂閱過濾規則決定哪些產品事件進入主題，擋掉了佔全部流量 55% 的營運事件，讓主題小到能負擔七天保留期，也就有了重放能力。
第二個決定是整個處理圖只用一個 Flink 1.20 作業，經 Flink Kubernetes Operator 部署，而不是每個產品一個作業。合併與拆分的原則很具體：
- 合併：過濾與解析合併，省掉重複的 JSON 解析；多個輸出用 side output 一次扇出。
- 拆分：I/O 密集的「解析與過濾」和 CPU 密集的「套用轉換」分開，各自調整平行度。
- 每個運算子都用
uid()固定。團隊踩過的教訓是：改 operator UID 會讓狀態被靜默丟棄，現在把 UID 當成 API 對待。
去重使用者數改用 HyperLogLog sketch，取代原本的使用者 ID 清單。60 秒窗口帶著 sketch，Impact API 在讀取時才依需要的維度合併；代價是約 1.5% 的誤差，以及 Java 生產端與 Go 消費端之間的格式耦合。
輸出端的 key 先於拓撲設計：鍵值儲存以產品、日、時、作業，加上窗口、租戶、子產品、體驗組成 key，重放只會改寫相同的資料列；Parquet 檔則隨 checkpoint 滾動。Flink 狀態放 RocksDB，每 30 秒 checkpoint 到物件儲存。
autoscaler 與設定管理
早期設定下作業每天完整重啟約 8 次。調整後採用 0.7 的目標使用率、0.3 的邊界、18 到 25 的頂點平行度與三小時的縮容間隔，穩態下零重啟。部署流程也加了檢查：10 分鐘內重啟超過 3 次就讓 pipeline 失敗。
設定集中在單一 products.yaml，以 CUE 定 schema，產生 Kafka 過濾規則、轉換、偵測門檻與 sink 路由。2026 年年中起，作業從物件儲存熱載入執行期設定包，新增產品不必再重新部署。
決策層與 OpenTelemetry
Go 寫的 AutoHOT 引擎雙區 active-active，兩區都消費每則告警，以業務去重 ID（而非佇列訊息 ID）在多區資料表上搶鎖，擁有者停擺五分鐘後由另一區接手。引擎每分鐘向 Impact API 查詢衝擊人數，依範圍套用嚴重度矩陣，例如單一租戶約 75 位使用者、單一 region 約 500 位、全球約 1,000 位；2 位以下視為雜訊。blip 偵測在 FY26 避免了約 300 次誤報呼叫。
可觀測性走 OpenTelemetry：Flink 作業以 OTLP 匯出指標到 Grafana Mimir，引擎則輸出 traces 與 OTLP 指標，Java 與 Go 兩端能在同一個視圖查看。另外每 15 分鐘注入一則假告警，走完「異常、衝擊分析、開單、關單」全流程，壞掉時 15 分鐘內就會發現。
實際效果
| 指標 | 之前 | 之後 |
|---|---|---|
| 事件到指標延遲 | 40 秒以上 | 10 秒以內 |
| 運算資源 | 約 90 台 VM 加佇列與快取層 | 4 個 Kubernetes pod |
| 每月成本 | 約 $20,000 | 約 $650（降 97%） |
| 作業重啟 | 每天約 8 次 | 穩態 0 次 |
| 儀表板衝擊查詢 | 約 10 秒 | 約 1 秒 |
影子運行兩週，與舊管線的資料一致性為 99.9%。停擺後可用 Kafka 重放在約 20 分鐘內恢復，不遺失資料。
偵測成果則沒那麼漂亮，文章照實列出。2025 年 3 月到 2026 年 8 月的範圍內召回率從 60% 到 6 月高點 86%，8 月回落到 64%。2025 年 11 月到 2026 年 7 月共 263 件重大事故，其中 117 件（44.5%）落在有埋點的體驗上，系統抓到 80 件，整體覆蓋率只有 30.4%。作者的結論是：召回率是偵測器的性質，覆蓋率是你選擇埋點範圍的結果，兩者要分開報告。
仍未解決的問題
- 沉默仍被當成健康：volume-drop 偵測在 2026 年 5 月抓到一件 Sev1，但 6 月因指標後端的攝入延遲被誤判為流量歸零而產生誤報，修正方式是加 120 秒最小延遲，等於用兩分鐘偵測時間換精準度。
- 量化落後於偵測：一件 Sev1 開單時顯示約 2,000 位使用者受影響，實際超過 80,000，因為計數儲存只記有失敗的租戶分鐘。
- 讀取時聚合撐不住：Impact API 每次請求都合併分鐘級 sketch，事故期間約 100 位同時使用的儀表板使用者就造成停機，後續改為 Flink 寫每日彙總加短 TTL 快取。
- 單一區域輸入：事件閘道、匯流排訂閱與 Flink 作業都在同一個 region，區域性雲端故障時運算正常但偵測失明。
影響範圍
正在自建即時偵測或 SLO 管線的團隊，可以直接對照幾個具體作法：在 bus 層做訂閱過濾、先設計冪等 sink key 再設計拓撲、用 sketch 取代 ID 清單、把 operator UID 與 autoscaler 參數視為正式設定。報告偵測品質的團隊則要檢查自己是否把召回率與覆蓋率混為一談。文章未公布 Flink job 的原始碼與完整設定檔。
原始來源：CNCF Blog 原文