Claude Tag：Anthropic CI/CD 故障初步分析中位數為 14 分鐘

Claude Tag：Anthropic CI/CD 故障初步分析中位數為 14 分鐘。核心定位 Anthropic 工程師 Sachin Malhotra 在 2026 年 8 月 18 日發布的文章中介紹，Claude Tag 已連續數月擔任 Anthropic CI/CD 故障的第一回應者；近期每起有撰寫情況報告的事件，第一份 SITREP 都由 Claude 產出，通常在 15 分鐘內完成初步分析。ClaudeDevs 於 2026 年 9 月 8 日補充，Claude Tag 會讀取 警示、metrics 與 logs，持續維護 lessons.md，讓下一次事件能參考過往經驗。事件處理結果 Anthropic 表示，Claude 在事件開啟後產出第一份有證據支持的分析，中位數為 14 分鐘；最快的案例能在第一份報告中於 4 分鐘內指出根因。文章舉例，一項新服務約 44 個測試停止觸發，Claude 找到原因是當天早上啟用的 feature flag，並判斷回復該設定是安全的；工程師執行回復後，Claude 在 3 分鐘後確認 skip rules 已移除，錯誤率也回到基準。setup kit Anthropic 同步分享 GitHub 上的 oncall-kit，將團隊既有的 警示討論串、pager history 與 postmortems 轉成 triage playbooks。每個 skill 都是描述單一工作的 Markdown 指令檔，例如如何分類警示或撰寫交接報告；團隊可像管理程式碼一樣審查、修改並提交這些檔案。產出的 Claude 在 incident channel 中以 read-only 方式運作，負責診斷、升級、提出修復方案與學習，不直接部署修復。不過，oncall-kit 明確標示為 reference implementation，目前不維護，也不接受貢獻。其 10 分鐘示範使用零個連線與虛構團隊的 48 起事件歷史，只能展示設定流程與驗證機制，不能建立正式環境行為的證據。Alert 與升級流程 Claude 並不是 detector。既有 alerting 仍負責發出警示，Claude 觀察指定的 alert channels、分類觸發的事件，並跨通道合併相關警示；repository 指出，五個 警示 常常其實屬於同一個 incident。新服務開始運作的前幾天，Claude 可分析資料與進來的警示，提出額外規則並微調過寬或過窄的規則。若新服務尚無警示，oncall-kit 則可先草擬較保守的起始規則，供人類在上線前安裝。Alerting 本身採 deterministic 路徑，但 on-call escalation 同時具備 deterministic 與 agentic 路徑。Claude 可依 ONCALL.md 或 root oncall.md 中的條件判斷是否立即 page on-call，或只寫入早上的摘要。例如錯誤率超過 2% 且持續 5 分鐘、同時不在已知 deploy window 時，才觸發 page；其他情況則記錄到 lessons.md。Alert-watch routine 會先在 shadow 狀態運作，必須等證據達到門檻；兩週後觸發強制審查，不會自動轉為正式上線，paging 也要另行作出 go/no-go 決定。平行調查架構 事件升級後，Claude Tag 會啟動 orchestration workflow，由 orchestration agent 建立 executor subagents，平行調查各個依賴與事實來源。Anthropic 的範例透過 MCP Connectors 連接 Grafana、日誌儲存系統、PagerDuty、GitHub、Kubernetes 與 Slack incident channels；各 executor 回報結果後，再由 orchestrator 彙整成可閱讀的 SITREP，以縮短 MTTR。調查不只是自由搜尋。Claude 會先載入對應的 investigation skill、參考 Markdown 檔案與 lessons.md。例如，處理 shadow divergence bugs 的 investigation skill 有 617 行，記錄工程師平時逐步排查的方法；重複出現的處理模式，則可從 lessons.md 提升為正式的 investigation skill。人類控制邊界 repository 將分工定義為：Claude 負責蒐集證據、提出方案、驗證結果與溝通；人類決定要如何、何時進行 mitigation。Claude 可提出包含 feature flag、百分比步驟、每階段等待時間與中止指標的 canary ramp plan，但不會直接碰觸 flag。人類或受控的 gated automation 才能部署修復，Claude 只持續觀察 metrics 是否回到基準，並在事件結束後把經驗追加至 lessons.md；事件始終由人類關閉。設定前提 要部署 Anthropic 文章描述的版本，流程包括：使用 Claude Team 或 Claude Enterprise 方案。 由 organization owner 透過 Claude Tag 將 Claude 加入 on-call Slack channel。 由 organization owner 在該頻道連接適當的 連接器、GitHub repo，並設定 Claude Code Remote。 將 Claude 加入 incident channel，要求它監控事件並立即進行 triage。Claude Tag 需要獨立的 service account、可讀取 metrics 與 logs 的權限，以及跨 on-call channel 保存的記憶。排程可在 Slack channel 以自然語言設定，例如要求每週一美東時間上午 9 點執行 CI handoff；相關 instructions 則放在 GitHub repo 的 skills 中。畫面示範 輔助畫面展示了一次 Slack 中的 payments-svc 測試事件：Marchfell 團隊的 Slack 介面截圖，顯示 #ci-oncall 頻道內一則由 Priya 標註 @oncall、指出 payments-svc 約 44 個測試停止觸發，部署日誌中未見相關紀錄的訊息，頻道標題列並顯示本週當值為 @Sachin 且 Claude 在此頻道中。Claude 找出一項使 44 個測試被靜音的 filter 變更；在人類要求確認重新命名的三個測試後，畫面顯示 Claude 以新限制各執行十次，共三十次測試，接著提出 PR #2213。Priya 核准並合併後，畫面顯示 build 4473 重新執行全部 44 個測試、錯誤率維持基準，Claude 再將結果寫入 lessons.md。這是示範流程中的畫面觀察，不是該 repository 對正式部署成效的獨立評估。Claude 在 Slack 通道中自動響應 on-call 警示並與團隊協同排查與合併 PR 的交談記錄成效缺口 目前資料只提供 Anthropic 自行報告的 14 分鐘中位數與 4 分鐘最快根因分析，沒有獨立評估 setup 在其他團隊的 operational outcomes 或 error rates；實際部署所需的完整 連接器 與 permissions、未維護 reference implementation 的後續適配方式，以及 proposed fixes 與 gated automation 在正式環境中的安全措施，來源也沒有進一步說明。原文：https://easyvibecoding.app/curated/3291-claude-tag-anthropic-cicd-failure-analysis-14-minutes