AWS DevOps Agent 把事故排查變成三步

AWS DevOps Agent 把散掉的事故訊號收斂成可重複的 triage 流程。

我跑過不少 incident call，最煩的不是故障本身，是那種大家一起找線索、卻永遠找不齊的混亂。Dashboard 在閃，Slack 在炸，然後每個人都在做同一套動作：看 logs、翻 traces、查 deploy、問誰改了東西，最後再多開三個 tab 祈禱其中一個講實話。AWS DevOps Agent 這東西，我一開始也沒抱太大期待，因為太多工具都說自己能幫你救火，結果只是換個地方讓你手忙腳亂。但我看完它的設計後，第一個反應不是「哇好強」，而是「終於有人想把前 20 分鐘的廢工做掉」。

我看的原始頁面是 AWS DevOps Agent。真正讓我停下來的是它不是只講聊天，不是只講摘要，而是直接碰 incident triage、root cause correlation、還有跨工具的 follow-through。它還把整個環境接到 Amazon CloudWatch、Dynatrace、Datadog、Grafana、New Relic、Splunk、GitHub、GitLab、Azure DevOps、ServiceNow、PagerDuty、Slack。這種範圍，才像真的在碰 ops，而不是在做 demo。

頁面裡的 Zenchef 例子也很有意思。工程師在 hackathon，監控沒直接給答案，卻有 downstream partner 受到影響。這種場景我信，因為它不浪漫，也不乾淨。沒人有空，問題又不能等，這時候工具如果只能講漂亮話，就等於沒用。DevOps Agent 在這裡的價值不是「聰明」，而是它願意先把髒活做完。

我最在意的不是 AI 會不會說話，是它會不會先把線索撿起來

AWS DevOps Agent autonomously triages incidents 24/7, providing root cause analysis and actions for resolution.

翻譯一下就是：AWS 想把 incident response 裡最耗人的那段，交給 agent 先跑一遍。不是叫它取代人，而是先幫你做 evidence collection、關聯分析、初步縮小範圍。這很重要，因為我看過太多團隊把 incident response 當成 scavenger hunt，大家比的是誰先猜中，而不是誰先拿到證據。

我自己碰過一個 production incident，root cause 其實早就在 deploy diff 裡了，但我們還是花了半小時在猜是不是 database 壞掉。原因很簡單：alert 只顯示 symptom，沒有把 change context 一起帶進來。人不是不能查，是每一步都在切工具、切畫面、切思路，最後把時間浪費在找入口。

DevOps Agent 想解的就是這個洞。它如果真的能把 telemetry、deploy history、ownership、runbook 串起來，第一輪 triage 就不再是「誰知道」，而是「證據在哪」。這種差別很務實，因為 incident 裡最貴的不是錯，而是大家都在用錯的順序查。

實操上，我會先不要碰工具，先畫你自己的 incident 流程。第一個 responder 會先看什麼？哪個系統有 change history？哪個地方記 ownership？哪個 channel 用來對外同步？你把這些寫清楚，才知道 agent 到底該補哪一段，而不是讓它又多一個入口。

• 列出 incident 的 source of truth：logs、traces、deploys、tickets、runbooks。
• 標出哪個系統有變更紀錄，哪個系統有 owner 資訊。
• 決定 agent 的輸出要落在哪裡：Slack、ServiceNow、PagerDuty。

如果你現在的資料本來就散，這種 agent 的價值才會明顯。因為它不是幫你創造答案，它是幫你把原本分散的答案湊成一張圖。

它真正該做的，不是回答所有問題，而是保住上下文

AWS 一直強調這個 agent 是 always-available，而且能讓你問問題、拿 contextual answers、做 custom charts 和 reports。這句話看起來很普通，但我覺得它踩到一個老問題：incident call 最大的成本，常常不是查不到，而是查到一半上下文斷掉。

我很討厭那種情況，因為你剛在某個圖上看到異常，切去另一個工具查 deploy，回來後已經忘了原本為什麼打開那張圖。這不是技術問題，是腦袋被 tab-switching 稅榨乾。DevOps Agent 如果能把 conversation history、查詢脈絡、以及每次假設的證據留住，那它就不是單純的 chatbot，而是比較像一個不會失憶的 junior SRE。

我特別在意它能不能做 recurring questions。很多團隊在事故時問的其實都差不多：最近 24 小時改了什麼？哪個 dependency 先壞？這次跟上次是不是同一種 pattern？哪個 deploy 跟 error spike 對上？如果每次都要重新拼一次，那就是在重演同一個悲劇。

實操寫法我會這樣做：先把團隊常問的問題列成固定清單，不要一開始就問「幫我看全部」。先從三到五個高頻問題開始，逼 agent 用固定格式回答。格式固定了，你才有辦法比較不同 incident 的差異。

• What changed in the last 24 hours?
• Which dependency failed first?
• What similar incidents happened before?
• Which deploy correlates with the first spike in errors?

如果它答不出來，別急著怪 agent。先看是不是你的 telemetry 根本不完整，或是資產關聯資料太爛。很多時候問題不在 AI，問題在你本來就沒把系統講清楚。

最值錢的不是止血，是把重複事故變成 backlog

AWS 這頁我覺得最務實的地方，是它沒有只賣 incident response，而是把 prevention 也一起拉進來。它說 agent 會分析歷史 incident pattern，然後給四類建議：observability、infrastructure optimization、deployment pipeline enhancement、application resilience。這四類很老實，因為真的就是大多數團隊在燒錢的地方。

我看過太多 postmortem 最後變成「我們要加強監控」「我們要改善流程」，然後呢？沒有然後。排進 backlog 之後就石沉大海。AWS 想做的是把這些建議變成可以交辦的東西，讓它可以接到 coding agent 或工程師，直接往 code、config、pipeline 去改。這才像在處理問題，不是在寫作文。

頁面上 Western Governors University 的案例很有代表性。他們說一個 production investigation 從預估兩小時縮到 28 分鐘，MTTR 改善 77%。更重要的是，它還找出 Lambda 設定問題，並挖出藏在內部文件裡的 operational knowledge。這種價值我認，因為它不只是快，而是把原本埋掉的知識翻出來。

實作上，我會把最近 10 個 incident 拉出來，先分群，不要急著上工具。你要問的是：這些事故到底是 telemetry 不夠、infra 太脆、pipeline 太亂，還是 app 本身太容易炸？如果同一類問題一直出現，那不是巧合，是 backlog 在敲你頭。

• 每週 review 最近 10 個 incident，按原因分群。
• 叫 agent 標出缺失或誤導的 signals。
• 把每個 recurring pattern 變成 ticket，指定 owner 和 deadline。

這樣做的好處是，你不只是在縮短這次事故的時間，你是在降低下次再見到同一種事故的機率。這才是比較像樣的 ops 工作。

整合不是附加功能，整合就是這個產品本體

這種 agent 如果不能跨工具看東西，基本上就只是另一個會講話的介面。AWS 這頁把整合寫得很直白：CloudWatch、Dynatrace、Datadog、Grafana、New Relic、Splunk、Azure DevOps、GitHub、GitLab、ServiceNow、PagerDuty、Slack，外加 private 或 remote MCP servers。這句話的意思很簡單：它不是只想待在 AWS 裡面，它想碰你整個 incident surface。

我很吃這一套，因為真實世界的事故本來就不是單點。alert 在一個地方，logs 在另一個地方，deploy 在第三個地方，ownership 在 ticket 系統，runbook 還可能躺在 repo 深處沒人更新。你如果不能跨這些邊界，就只是把麻煩換個 UI 顯示而已。

T-Mobile 的說法也點到這個重點。他們是 design partner，而且特別提到 Splunk 在 multicloud 與 on-prem 環境的整合。這很像 AWS 在講：我知道你不是全 AWS shop，我也知道你環境很髒，所以我得先能活在你的現實裡。

我以前待過一個環境，observability 不是沒有，是每個 team 各自一套。最後每次 incident 都變成「你的資料不準」「我的資料才是真的」。這種時候最缺的不是更多 dashboard，而是能把不同資料源串在一起的中介。Agent 如果做不到這件事，就沒有資格碰 production。

實操寫法很簡單：先把你的 toolchain 分成三類。第一類是要讀的，像 logs、metrics、traces、deploy history。第二類是要寫回去的，像 Slack、ServiceNow、PagerDuty。第三類是參考資料，像 runbook、ownership docs、內部 wiki。每一類都要定義權限，不然 agent 不是幫忙，是在亂跑。

• 能不能讀 logs、metrics、traces、deploy history、ownership metadata？
• 能不能把 findings 寫回 responders 已經在看的地方？
• 能不能透過 MCP 接 custom tools？
• 能不能在整個 investigation 中保留 context？

如果這四題有一題答不出來，你就先別談 rollout。先補整合，不然只是在加一層新噪音。

Zenchef 那個案例，比大部分企業故事都更像真的

我最信 Zenchef 這種例子，因為它沒有把場景包裝成英雄故事。工程師在 hackathon，大家忙到沒空，監控又沒直接給答案，偏偏 downstream partner 受影響。這種狀況下，工具如果不能幫忙縮小範圍，那它就只是多一個需要被忽略的介面。

AWS 說 DevOps Agent 先排除了 authentication，再把焦點轉到 ECS deployment，最後追到 database 裡一個 unrecognized enum value 的 code regression。整個 investigation 20 到 30 分鐘，原本人工預估要一到兩小時。這不是炫技，這是把一堆不確定性按順序剝掉。

我喜歡這個案例，因為它證明 agent 的價值不是「它很會猜」，而是它會先做排除法。Ops 最需要的就是這種能力。你不一定要它直接說出真相，但你要它能告訴你：哪些方向已經不太像，哪個方向值得先查。

這也牽涉到信任問題。只要它能清楚說明為什麼排除某個假設，工程師就比較願意用。反過來，如果它只給一個結論，卻不交代證據鏈，那第一次猜錯之後，大家就會把它當裝飾品。事故現場不缺漂亮話，缺的是可驗證的判斷。

實操上，我不會先拿它去打最嚴重的 outage。我會先找一個已知 root cause 的低風險 incident，讓 agent 跑一次。看它能不能找到同樣的路徑，看它的解釋是不是可用，看它是不是能把結果變成真正能交辦的內容。

最後你只要問團隊一個很直接的問題：這東西是幫我們省時間，還是只是把工作換個地方做？如果是前者，就繼續加深整合；如果是後者，就先回去補資料、補流程、補權限。

可抄的模板

# AWS DevOps Agent rollout template for incident triage

## 1) Incident sources
- Observability: CloudWatch, Datadog, Dynatrace, Grafana, New Relic, Splunk
- Code and deploy history: GitHub, GitLab, Azure DevOps
- Coordination: Slack, ServiceNow, PagerDuty
- Custom systems: MCP-connected internal tools

## 2) Questions the agent must answer
1. What changed in the last 24 hours?
2. What dependency failed first?
3. What evidence supports the current root cause hypothesis?
4. What similar incidents happened before?
5. What fix should we apply next?

## 3) Standard incident output format
- Incident summary
- Affected services
- Timeline of events
- Top 3 hypotheses
- Evidence for each hypothesis
- Root cause
- Immediate mitigation
- Recommended follow-up work
- Owner and next action

## 4) Prevention workflow
- Review the last 10 incidents weekly
- Group incidents by cause: observability, infra, pipeline, app resilience
- Convert each repeat pattern into a ticket
- Require an owner, due date, and expected signal improvement

## 5) Agent handoff rules
- If confidence is low, ask for more telemetry instead of guessing
- If a deploy is implicated, include commit and release references
- If a ticket is needed, open it with the investigation context attached
- If a fix is suggested, make it actionable for a human or coding agent

## 6) Output to share with the team
- Slack summary for responders
- ServiceNow incident notes
- PagerDuty update for on-call
- Follow-up report with charts and trend lines

## 7) Evaluation checklist
- Did the agent reduce time to first useful hypothesis?
- Did it correlate logs, metrics, traces, and deploys?
- Did it explain why it ruled out other causes?
- Did it produce a fix the team could actually use?
- Did it reduce repeat investigations over time?

這段模板是我根據 AWS DevOps Agent 頁面和它公開的案例整理出來的，原始來源是 https://aws.amazon.com/devops-agent/。上面的 rollout 結構、問句清單、輸出格式是我衍生後重寫的，可直接複製；AWS 原文提供的是方向，我補的是能真的拿去內部落地的版本。

如果你要我一句話總結，我會說：這不是拿 AI 來裝飾 incident response，而是把前半段最亂、最耗人的 triage 變成一套可重複的工作流。先把線索撿齊，再談修復，這樣才像在做 ops。