用 Codex 做 Production Monitoring：Grafana、Kubernetes 與資安
🏦 台灣Pay 銀行轉帳 💙 PayPal
示範用 Codex 的 skill 與 security plugin 調查並修復正式環境事故
- 00:02 情境：凌晨 3 點被叫醒，checkout 錯誤率上升，打開 Grafana 卻不知從何下手
- 03:57 使用 Kubernetes rollout investigator skill 調查這次 rollout，找出問題所在並辨識 causal chain
- 07:35 講者表示這方面還有很多尚未整合的 lateral plays，鼓勵大家自行探索
💡 你可以怎麼用：如果你有接觸線上服務，可以先把出事時的排查步驟寫成 skill，例如要看哪幾張圖表、要比對哪次更新，讓 Codex 照著查。同時保留 approve 這一步，由自己做最後決定。
看全部 28 條重點
🧑🏫 這支影片示範線上服務半夜出事時，怎麼請 OpenAI 的程式 AI 助手 Codex 幫忙查原因、提出修法，人只要按下核准。影片用三個例子說明：新版本上線出錯、Kubernetes 連鎖故障，以及一個過度耗資源的請求拖垮系統。值得看的原因是，它把「出事時到處翻資料」這段最累的工作交給 AI，修好的時間可以從一小時左右縮短到幾分鐘。
- 00:02 情境：凌晨 3 點被叫醒，checkout 錯誤率上升，打開 Grafana 卻不知從何下手↳ 凌晨三點被叫醒，結帳（checkout）出錯變多。打開 Grafana（把系統數據畫成圖表的儀表板工具）卻滿螢幕都是圖，不知道該先看哪裡。這是事故當下最常見的困境。
- 00:02 處理事故要先釐清哪些地方受影響、改了什麼；dashboard 只是一部分，還需要部署脈絡和相關程式碼，蒐集這些資訊很重複、很耗工↳ 處理事故，第一步是搞清楚哪裡壞了、最近改了什麼。dashboard（儀表板）只看得出數字變了，原因還得去翻部署紀錄和程式碼。這種到處翻找的工作又重複又花時間。
- 00:36 例一：推出新版本後，目前 release 為 v2，但 checkout error rate 升到約 20%，原因不明↳ 例一：剛上線新版本 v2（release 指一次正式發佈的版本），結帳失敗比例（checkout error rate）就衝到約 20%，等於每五筆失敗一筆，但沒人知道為什麼。
- 00:36 使用 Codex 搭配 custom skill 調查 checkout 相關證據↳ skill 是事先寫好的一套工作指引，讓 Codex 照固定步驟做事。這裡用的是自訂的 custom skill，專門去查跟結帳有關的線索。
- 01:15 Codex 檢查成功的 checkout、response time、service health 等資訊，幾秒內就回報結果↳ Codex 自己去看成功結帳數、response time（系統多久回應）和服務健康狀態，幾秒就整理出結果。人不用再一個畫面一個畫面點開來看。
- 01:15 輸入 approve 後推出修好的新版本，checkout error rate 回到 0↳ Codex 提出修正後，人輸入 approve（核准）才會執行，接著推出修好的新版本。結帳錯誤率回到 0，代表問題真的解決了。
- 01:47 修復時沒有 revert 回舊版，仍然是 v2；Codex 是用 repository 的 bounded evidence workflow 和 release diff 來調查並修復↳ revert 是退回舊版，常見的止血做法。這次沒有退，版本仍是 v2。Codex 照專案裡限定查證範圍的流程（bounded evidence workflow），比對版本差異（release diff），直接把問題修掉。
- 01:47 這個 Grafana dashboard 主要看 checkout health、目前的 release 版本、error rate 和 P95 指標↳ 這個儀表板主要看四件事：結帳是否健康、目前跑哪個版本、錯誤率，以及 P95。P95 是指 95% 的請求都能在這個時間內完成，用來看大多數人要等多久。
- 02:17 手動處理時，工程師要自己找 logs、其他 dashboard、程式碼變更；改用 Codex 後，把這些手動蒐集工作交給 agentic process，由它提出修正↳ 以前工程師要自己翻 logs（系統運作紀錄）、切換其他儀表板、查程式改動。現在這些跑腿工作交給 agentic process（AI 自己規劃、連續執行多個步驟），由它查完提出修法。
- 02:51 由 human in the loop 核准修正後，幾分鐘內就能上線，不必經歷約一小時的手忙腳亂↳ human in the loop 是指流程中保留由人做關鍵決定：AI 提方案，人點頭才上線。這樣修正幾分鐘就能上線，不用手忙腳亂折騰一小時左右。
- 02:51 例二：同樣做法也適用於 containers 和 Kubernetes clusters；範例應用包含 inventory API cluster、orders API cluster 與 edge gateway↳ 例二換成 container（把程式連同執行環境打包在一起的單位）和 Kubernetes cluster（統一管理一群 container 的系統）。範例有庫存 API、訂單 API，以及 edge gateway（外部請求的入口）。
- 03:27 推出新版 inventory API，雖然通過 CICD workflow，container 仍被 OOM killed↳ 新版庫存 API 通過了 CICD workflow（程式改完後自動測試、自動部署的流程），上線後 container 卻被 OOM killed，也就是記憶體用超過上限，被系統強制關掉。測試通過不代表上線就沒事。
- 03:27 這個問題造成 cascading failures，整個 cluster 都掛了↳ 一個服務倒下，依賴它的服務也跟著出錯，一個拖垮一個，這叫 cascading failures（連鎖故障）。結果整個 cluster 停擺，不只庫存功能壞掉。
- 03:57 使用 Kubernetes rollout investigator skill 調查這次 rollout，找出問題所在並辨識 causal chain↳ rollout 是把新版本換上線的過程。這裡用專門調查 rollout 的 skill，不只找出哪裡壞，還整理出 causal chain（因果鏈）：哪一步先出錯，又怎麼一路影響其他服務。
- 03:57 講者認為辨識 causal chain 是 Codex 對資安與 production monitoring 最有價值的地方↳ 講者認為最有價值的不是看到錯誤，而是說清楚「因為 A，所以 B，所以 C」。知道源頭在哪，才不會只修表面症狀。這一點對資安和監控都很重要。
- 03:57 patch 準備好後點 approve，推出新版 inventory API container↳ patch 是修補程式。Codex 備好 patch 後，人點 approve，系統就推出修好的新版庫存 API container。決定權仍然在人手上。
- 04:30 服務恢復到 healthy baseline：orders API 正常運作，edge gateway 重新上線↳ 服務回到 healthy baseline（平常正常運作的狀態）：訂單 API 恢復正常，入口 edge gateway 也重新上線，連鎖故障跟著解除。
- 04:30 流程與例一相同：工程師不自己蒐集資訊，交給 Codex，並在 Codex 提出修正時保持在 loop 中，修復速度比自己做快很多↳ 流程和例一一樣：蒐集資訊交給 Codex，人只在它提出修正時把關。比起自己一項一項查，修好的速度快很多。
- 05:02 兩個例子中都是人先被 page，再進 Codex 讓它提出修正↳ 兩個例子的起點都是人先被 page（被監控警報通知、叫醒）。收到通知後，人才打開 Codex，請它調查並提出修正。
- 05:02 替代做法：在 Kubernetes、Grafana 或其他 observability platform 裡自架 runners，監控超出 baseline 的 alerts，並由這些 alerts 觸發 Codex↳ 另一種做法：在 Kubernetes、Grafana 等 observability platform（觀察系統狀況的監控平台）裡自架 runners（持續待命執行任務的程式）。警報一超出正常範圍，就自動叫 Codex 開始處理。
- 05:34 這樣可以把從 alerting 到提出修正的整個流程完全自動化↳ 這樣從警報響起到提出修法，整段都能自動完成，不必等人被叫醒、打開電腦才開始查。
- 05:34 也可以建立 multi-agent system，讓其他 agents 驗證修正並推出，完全把人移出 loop↳ 再進一步，可以建立 multi-agent system（多個 AI 分工合作的系統）：一個 AI 提出修正，其他 AI 負責驗證和上線，連核准這一步都不需要人。
- 06:04 production monitoring 和資安有交集；例三同時使用 production monitoring 與 Codex security，確保服務持續可用↳ 監控和資安其實有交集：服務被拖垮，不一定是程式壞了，也可能是請求本身有問題。例三同時用監控和 Codex 的資安功能，目標是讓服務持續可用。
- 06:35 例三情境：最近沒有部署，卻有一個 report request 拖垮 checkout 和 shared worker pool，也就是單一請求一次吃掉太多資源↳ 例三最近沒有更新任何東西，卻有一個產報表的請求（report request）一次吃掉大量資源，把結帳和 shared worker pool（多個功能共用的一組處理程序）一起拖垮。
- 07:05 核准由 Codex security plugin 產生的 patch，replay 該請求後，這個非常昂貴的請求已被成功擋下↳ Codex security plugin（Codex 的資安擴充功能）產生 patch，人核准後，把同一個請求 replay（重送一次）來測試，確認這種過度耗資源的請求已經被擋下來。
- 07:05 這個例子是用資安需求修好了 production monitoring 的問題↳ 這題表面上是「系統被拖垮」的監控問題，解法卻來自資安角度：把過於昂貴的請求擋在外面，問題就解決了。
- 07:05 講者個人大力推薦 Codex security plugin，稱它非常強大↳ 講者個人大力推薦 Codex security plugin，說它非常強大。這是講者的個人看法，影片裡沒有提供具體數據佐證。
- 07:35 講者表示這方面還有很多尚未整合的 lateral plays，鼓勵大家自行探索↳ 講者說還有很多把不同工具橫向搭配的玩法（lateral plays）尚未整合，鼓勵大家自己動手試試看。
📘 術語
Grafana（Grafana 監控儀表板）：事故發生時打開來看的 dashboard，可看到 checkout health、release 版本、error rate、P95
checkout error rate（結帳錯誤率）：例一中上線 v2 後升到約 20%，修復後回到 0
custom skill（自訂 skill）：搭配 Codex 使用，用來調查 checkout 相關證據
bounded evidence workflow（有範圍的證據蒐集流程）：Codex 用 repository 裡的這個流程搭配 release diff 調查並修復問題
release diff（版本差異）：字幕只提到 Codex 用它來調查並修復問題，未進一步解釋
revert（退回舊版）：字幕強調修復時沒有 revert 回舊 release，仍跑 v2
P95（P95 指標）：Grafana dashboard 上觀察的指標之一，字幕未進一步解釋
agentic process（agent 式流程）：把手動蒐集資訊的工作交給它，由它提出修正
human in the loop（人在流程中把關）：Codex 提出修正後，由人核准（approve）才上線
Kubernetes cluster（Kubernetes 叢集）：例二的應用由 inventory API、orders API cluster 與 edge gateway 組成
edge gateway（邊緣閘道）：例二應用的組成元件之一，cluster 恢復後重新上線
CICD workflow（CI/CD 流程）：新版 inventory API 雖通過它，container 仍被 OOM killed
OOM killed（記憶體不足被終止）：字幕只提到 container 被 OOM killed，未進一步解釋
cascading failures（連鎖故障）：OOM killed 引發的連鎖問題，導致整個 cluster 掛掉
Kubernetes rollout investigator skill（Kubernetes rollout 調查 skill）：用來調查目前 rollout，找出問題與 causal chain
causal chain（因果鏈）：講者稱辨識它是 Codex 對資安與 production monitoring 最有價值之處
healthy baseline（健康基準狀態）：修復後服務回到的正常狀態
runners（執行器）：可自架在 Kubernetes、Grafana 等平台，監控超出 baseline 的 alerts 並觸發 Codex
observability platform（可觀測性平台）：字幕舉 Kubernetes、Grafana 為例，可在其中自架 runners
multi-agent system（多 agent 系統）：讓其他 agents 驗證修正並推出，人可完全退出 loop
shared worker pool（共用 worker pool）：例三中被一個 report request 拖垮的資源
Codex security plugin（Codex 資安外掛）：例三中產生 patch，成功擋下過於昂貴的請求
replay（重送請求）：套用 patch 後重送該請求，確認已被擋下
checkout error rate（結帳錯誤率）：例一中上線 v2 後升到約 20%，修復後回到 0
custom skill（自訂 skill）：搭配 Codex 使用，用來調查 checkout 相關證據
bounded evidence workflow（有範圍的證據蒐集流程）：Codex 用 repository 裡的這個流程搭配 release diff 調查並修復問題
release diff（版本差異）：字幕只提到 Codex 用它來調查並修復問題，未進一步解釋
revert（退回舊版）：字幕強調修復時沒有 revert 回舊 release，仍跑 v2
P95（P95 指標）：Grafana dashboard 上觀察的指標之一，字幕未進一步解釋
agentic process（agent 式流程）：把手動蒐集資訊的工作交給它，由它提出修正
human in the loop（人在流程中把關）：Codex 提出修正後，由人核准（approve）才上線
Kubernetes cluster（Kubernetes 叢集）：例二的應用由 inventory API、orders API cluster 與 edge gateway 組成
edge gateway（邊緣閘道）：例二應用的組成元件之一，cluster 恢復後重新上線
CICD workflow（CI/CD 流程）：新版 inventory API 雖通過它，container 仍被 OOM killed
OOM killed（記憶體不足被終止）：字幕只提到 container 被 OOM killed，未進一步解釋
cascading failures（連鎖故障）：OOM killed 引發的連鎖問題，導致整個 cluster 掛掉
Kubernetes rollout investigator skill（Kubernetes rollout 調查 skill）：用來調查目前 rollout，找出問題與 causal chain
causal chain（因果鏈）：講者稱辨識它是 Codex 對資安與 production monitoring 最有價值之處
healthy baseline（健康基準狀態）：修復後服務回到的正常狀態
runners（執行器）：可自架在 Kubernetes、Grafana 等平台，監控超出 baseline 的 alerts 並觸發 Codex
observability platform（可觀測性平台）：字幕舉 Kubernetes、Grafana 為例，可在其中自架 runners
multi-agent system（多 agent 系統）：讓其他 agents 驗證修正並推出，人可完全退出 loop
shared worker pool（共用 worker pool）：例三中被一個 report request 拖垮的資源
Codex security plugin（Codex 資安外掛）：例三中產生 patch，成功擋下過於昂貴的請求
replay（重送請求）：套用 patch 後重送該請求，確認已被擋下
✏️ 小考一題
在 Grafana 的 checkout 錯誤例子中，Codex 修好問題後，服務跑的是哪個版本？
A. 升級到 v3B. 退回到上一個穩定的 container imageC. 仍是 v2，沒有 revert 回舊版D. revert 回 v1看答案
答案：C。[01:47] 字幕說 we did not revert back to an old release. We are still on v2.
💛 覺得有幫助？支持一下
課本免費、沒有廣告，支持與否都能照常讀 🐰