DevOps／SRE 維運工程師：把 Claude Code 與 Codex CLI 用進值班日常

A · 官方資源脈絡↑ 回案例選單

DevOps／SRE 是 Claude Code 語料最豐富的職業之一——維運場景本來就是官方與社群雙重主打的舞台。

Anthropic 官方部落格《How Anthropic teams use Claude Code》寫了兩個具體到能直接引用的內部案例：Data Infrastructure 團隊遇到 Kubernetes pod 排程不上去的停機事件，工程師把儀表板截圖直接餵給 Claude Code，它一步步帶工程師操作 Google Cloud 介面，診斷出 pod IP 位址耗盡，給出建立新 IP pool 加入叢集的確切指令——「在系統停機時省下 20 分鐘」；另外用 CLAUDE.md 讓新進資料科學家理解資料管線相依，取代傳統 data catalog。Security Engineering 團隊則是事件發生時把 stack trace 與文件餵給 Claude Code 追蹤控制流，「原本 10–15 分鐘的手動翻程式碼，現在快 3 倍解決」。✅官方

Claude Cookbook《The site reliability agent》是官方完整教材：用 Agent SDK + 自建 MCP server（Prometheus 查詢、Docker logs、設定檔編修）做全自動事件處理——健康基線 → 注入故障 → 唯讀調查 → 修復 → 驗證 → 自動寫 postmortem，一條龍跑完。安全機制寫死在工具層：寫入僅限 config/ 目錄、shell 指令白名單只放行 docker／docker-compose、PreToolUse hook 驗證數值範圍。官方原話講得很白：「工具描述比華麗 prompt 更能驅動 agent 行為。」✅官方

OpenAI 官方的 Codex CLI 也有完整對應文件：安裝 curl -fsSL https://chatgpt.com/codex/install.sh | sh；/permissions 控制何時可改檔或跑指令；sandbox 分三檔——read-only（headless 預設，審查任務用這檔）、workspace-write、danger-full-access（CI 裡非必要別用）；codex exec 是非互動模式，進度流到 stderr、結果印到 stdout，方便接 grep／jq；/init 產生對應 CLAUDE.md 的 AGENTS.md。✅官方

B · 值班與事件應對：從第 1 頁直接跳到第 5 頁↑ 回案例選單

場景 1：凌晨三點的事件分流（incident triage）

值班工程師被 PagerDuty 叫醒後，光是把警報、Datadog 圖表、最近部署、Slack #incidents 頻道的上下文載入腦中，就要 8 分鐘以上才能形成第一個假設。

工作流（Claude Code + PagerDuty／Datadog／Slack／GitHub 四個 MCP server）：

1. 把 PagerDuty 警報 payload 餵給 Claude Code
2. 關聯受影響時間窗內的 Datadog 訊號
3. 用 GitHub MCP 查最近部署，按 service graph 距離排序候選部署（附 commit SHA）
4. 掃 Slack #incidents 找相關故障
5. 產出兩句話摘要 + 前三名訊號（附直接連結）+ 候選部署排名
6. 值班者只做驗證：核對摘要、排除虛假關聯、決定下一步調查方向

端到端 2–3 分鐘完成分流；文中引述 Grafana 用類似模式做到「time to root cause 縮短 3.5 倍」。🧪未驗證

場景 2：Kubernetes 叢集故障排查

接續 A 節提到的 Anthropic 官方案例（截圖診斷 pod IP 位址耗盡），社群更通用的做法是直接掛 Kubernetes MCP server，讓 Claude Code 用自然語言查叢集：

💡 前置：裝好 kubectl、有效 kubeconfig、Node.js，一行接上

claude mcp add kubernetes -- npx kubernetes-mcp-server

接上之後可以對話式操作：列 pod、describe deployment、tail logs、scale replicas、apply manifest；排查範例像是「找出 payments namespace 裡 CrashLoopBackOff 的 pod，讀它最近 100 行 log，對照 deployment 的 resource limits，告訴我最可能的原因」（此類 prompt 延伸自通用用法，非逐字轉述單一來源）。

權限設計是這節的重點：三層模型——production 唯讀（get/list/describe/logs）→ staging 可寫（加 apply/scale/patch）→ 只有本機／dev 叢集給完整權限。關鍵句：「MCP server 繼承你 kubectl context 的權限。如果 context 是 cluster-admin，Claude 就是 cluster-admin。」防線要建在 Kubernetes RBAC，不是 MCP 設定；每個 MCP 實例也該鎖定特定 kubeconfig context，避免跨叢集誤操作。✅官方

工具選型可考慮 containers/kubernetes-mcp-server（Go 原生實作、支援非破壞模式、secrets 遮罩、OpenTelemetry）、Flux159/mcp-server-kubernetes（TypeScript）、Blankcut（GitOps 向，整合 ArgoCD）。

C · Runbook 與 Postmortem：AI 做考古，人做因果↑ 回案例選單

場景 3：Runbook 執行與防漂移

Runbook 會漂移——一季才用一次的那份，裡面常常躺著已下架的工具、改過名的叢集，新工程師凌晨三點根本找不到對的那份。

工作流 A（事件當下找對 runbook）：Claude 拿警報 metadata（服務、症狀、tags）比對 runbook 索引，從 Confluence 撈出最佳候選，攤開診斷序列——每步的確切指令、目標系統、預期輸出。值班者在自己的終端機用受限憑證逐步執行、記錄每步 pass/fail，Claude 不直接對 production 執行。選錯 runbook 時人工重新指向，回饋改善索引。

工作流 B（批次防漂移）：讓 Claude Code 定期把所有 runbook 對 staging 環境重放一遍，標出指向已棄用工具或改名基礎設施的指令，依現行環境重新生成步驟。

工作流 C（用 CI 守 runbook 品質）：一句 prompt 讓 Claude Code 建 GitHub Actions pipeline——「為我們的 runbooks 建一條 pipeline：檢查格式、驗證必填欄位、確認必要章節存在（Problem／Solution／Validation steps）、檢查拼字、遵守命名規則，驗證失敗就擋下 PR。」Claude 會產出格式驗證腳本、內部連結檢查、必要章節驗證、PR 回饋。👤達人個人

場景 4：Postmortem 草稿自動化

寫一份 postmortem 要在 Slack 捲動回放、PagerDuty 時間軸、Datadog 圖、部署紀錄之間做 60–90 分鐘的「考古」，結果常是死線前趕出來的潦草草稿。

工作流（Claude Code + Slack／PagerDuty／Datadog／Confluence MCP）：Claude 從四個系統組裝完整考古材料，填入團隊範本——時間軸（每條目附回 Slack 訊息、metrics 面板、commit 的來源連結）、影響評估、受影響服務、證據引註。刻意留白：root cause、contributing factors、action items 三個欄位結構性空白，強制人來寫。值班者校時間軸、補漏掉的訊號（客服信、關聯事件、更早埋雷的部署），做 5 whys。

成效：60–90 分鐘考古壓縮成附來源連結的自動草稿；人只做審核與因果分析。留白設計不是保守，是有代價的教訓——Zalando 早期導入 AI 做 postmortem 因果分析時，幻覺率一度高達 40%。🧪未驗證

D · SLO 審查與 On-call 交接：把重複勞動排程化↑ 回案例選單

場景 5：SLO 調查與 error budget 審查

每週一的 error budget 審查會前，要把預算燃燒對應到具體事件、回歸時間窗、部署歷史、postmortem 主題，手動關聯要 4–6 小時。

工作流（Claude Code + Datadog／PagerDuty／Snowflake／Confluence MCP）：拉出審查窗內的 SLO/SLA 差異 → 撈同時段所有 PagerDuty 事件 → 按時間與服務把每個事件 join 到對應的 Datadog 回歸 → 從 Confluence 撈 postmortem 的 root cause 段 → 按團隊既有分類法把根因分組 → 產出結構化簡報：error budget 差額、事件清單、主題分組、未解問題。AI 明確不做的事：不量化因果比例（不寫「這個事件造成 35% 的燃燒」）——「AI 負責獵，人負責判。」

成效：4 小時備料壓到 30 分鐘審核修正。

場景 6：On-call 交接自動化

交接品質與交班者的疲勞度成反比——事件最多的班，交接寫得最爛，而那正是最需要交接的班。漏掉的上下文（還在 baking 的部署、進行中的事件、正在燃燒的 SLO）造成不必要的升級。

工作流（Claude Code + PagerDuty／Datadog／Slack／Zendesk MCP）：在輪班交界自動觸發（不用手動）→ 拉過去 24 小時所有 page 與處理備註 → 彙整進行中事件、baking 中的部署、SLO 越線 → 掃 #incidents 未解 thread 與 Zendesk 升級單 → 列出指派給本輪值的未結 action items → 透過 Slack DM + Confluence 文件送達交班簡報。交班者只補「只存在他腦中的」人為判斷：哪些是假警報、哪個客訴要盯、哪個部署有風險、哪些警報被靜音及其理由。

E · Terraform：安全審查對照與日常工作流↑ 回案例選單

場景 7：Terraform 安全審查——Codex 與 Claude Code 同場景直接對照

資安／維運工程師要在上 production 前審查整個 Terraform repo：誰能碰 production、哪些服務曝露在網際網路、IAM 權限是否過寬、加密與稽核紀錄是否齊全。這是本篇筆記裡唯一一組「同一份 repo、兩套工具各做一次」的直接對照。👤達人個人

💡 Claude Code 工作流：本機終端、真工具驗證

# 先開專用審查分支，寫 CLAUDE.md 定審查範圍與輸出格式
git clone git@github.com:your-org/terraform-platform.git
cd terraform-platform
git checkout -b security/iac-review-ai-assisted
claude

先讓 Claude 做 repo 地圖（唯讀理解），再開始評估；接著讓它實際執行驗證工具：terraform fmt -check -recursive、terraform validate、checkov -d .、tfsec .、trivy config .，安全的話再跑 terraform plan；最後讓它解讀掃描器輸出、排優先級，對確認的高風險項產出最小修補，用 git diff 驗證變更。

Codex CLI 對照則是雲端、repo 級路線：把 Codex 以最小權限接上 GitHub repo，開同名審查分支，先做唯讀整體評估（聚焦 IAM、公開曝露、加密、logging），再做分領域深查（IAM／網路／儲存／state backend），產出結構化發現（嚴重度、檔案路徑、業務影響），確認後才要求最小修補。

場景 8：Terraform 日常工作流——四階段漸進

Claude Code 幾秒鐘就能生出基礎設施程式碼，但 Terraform 後端要花幾分鐘消化；state 全域鎖、整份 refresh、序列執行讓 AI 的速度優勢卡在管線上。

1. Phase 1 唯讀理解：session 開頭先讓 Claude 解釋 module 結構、追 provider 設定、總結既有基礎設施——什麼都還不生成
2. Phase 2 受約束生成：prompt 要指名慣例，例如「在這個 repo 加一個應用上傳用的 S3 bucket，遵循既有命名慣例、開版本控制、開 AES256 伺服器端加密」
3. Phase 3 agent 迴圈：讓 Claude 生成 → 跑 validate → 讀錯誤 → 自行迭代，中間不用人工介入
4. Phase 4 稽核：利用 Claude 的閱讀能力做安全審查與跨大型 repo 的相依分析

佐證案例：有工程師用 Claude 生成可重用的 Azure VM Terraform module（多 VM、變數驅動、backend state 存 Azure），並示範用 claude-code-sdk（Python）程式化呼叫，結論是「這是超高速的範本化，不是自主開發」，hallucination（不存在的 API endpoint）仍需人工修正。terraform plan 的輸出也可以直接 pipe 給 claude -p 做自動安全審查、輸出 markdown。👤達人個人

F · CI/CD 工程化：headless 對照與慣例工程化↑ 回案例選單

場景 9：CI/CD headless 自動化——claude -p 對照 codex exec

想讓 agent 在無人值守下跑：git push 觸發、PR 留言觸發、夜間 cron、CI stage——讀 prompt、做事、吐出機器可讀結果。

# 基本：print 模式
claude -p "Summarize the changes in the last commit"

# 結構化輸出 + 解析
response=$(claude -p "Review PRs" --output-format json)
result=$(echo "$response" | jq -r '.result')
cost=$(echo "$response" | jq -r '.total_cost_usd')

# 唯讀審查者：工具白名單
claude -p "Review this diff for bugs" --allowedTools "Read,Grep,Glob"

# 範圍化 bash + 拒絕清單
claude -p "Summarize git history" \
  --allowedTools "Bash(git log *)" "Bash(git diff *)" "Read" \
  --disallowedTools "Bash(rm *)"

# 成本五道閘：回合上限、預算上限、模型路由、逾時、並發鎖
timeout 600 claude -p "Apply fixes" --max-turns 10 --model sonnet --output-format json

GitHub Actions 用官方 anthropics/claude-code-action@v1，prompt 之外帶 claude_args（如 --max-turns 12 --model sonnet --allowedTools "Read,Grep,Glob"）；認證三條路——ANTHROPIC_API_KEY／Bedrock OIDC／Vertex WIF，優先聯邦式身分而非長效金鑰。三層護欄取代人工按「允許」：--allowedTools 白名單、--permission-mode dontAsk（未列工具自動拒絕）、PreToolUse hooks 做決定性否決（如「禁止 push 到 production」）。適合自動化的任務要有三個性質：冪等、範圍受限、可驗證。誠實測試句：「如果這個任務凌晨三點照 prompt 字面執行，沒人審我也放心嗎？」👤達人個人

Codex CLI 對照（官方 cookbook：自動修 CI 失敗）：codex exec 是非互動模式，進度流 stderr、結果印 stdout、乾淨退出碼，方便接 jq。官方範例是主 CI workflow 失敗後觸發 Codex Auto-Fix workflow，Codex 以 workspace-write sandbox 分析 repo，prompt 明令「找出讓所有測試通過的最小變更，只做那個變更，然後停」，跑 npm test 驗證後開 PR，人審後合併；CI 認證一律用存在 repo secrets 的 API key，不要用 ChatGPT 瀏覽器登入；審查類任務一律 read-only sandbox。GitHub Actions 有官方 openai/codex-action@v1。✅官方

GitHub Copilot CLI 對照（原生 GitHub Actions 整合）：Claude Code 與 Codex CLI 接上 CI，都得另外準備一把 ANTHROPIC_API_KEY 或 OpenAI API key 存進 repo secrets——多一項要盯有效期、要輪替、外洩要撤銷的憑證。Copilot CLI 因為是 GitHub 自家產品，多一條能整個繞開這個問題的路徑：workflow 的 permissions 區塊加一行 copilot-requests: write，就能直接沿用 Actions 內建、範圍已經收斂好的 GITHUB_TOKEN，不用另外申請、保管一把獨立長效金鑰（另一條路徑仍可選用帶「Copilot Requests」權限的 PAT，經 COPILOT_GITHUB_TOKEN 注入，適合需要更細緻權限模型的情境；用 GITHUB_TOKEN 這條路徑組織管理員還得先在 Copilot CLI policy 開啟「Allow use of Copilot CLI billed to the organization」）。對天天在管憑證庫存的 DevOps 團隊來說，這是實質砍掉一項要維護的金鑰，不是紙面上的方便。✅官方

它同時內建 GitHub MCP server——預設所有唯讀工具（讀 PR、列 issue、查 commit）開箱可用，不用像接 Claude Code／Codex CLI 那樣得自己再另外裝一個 GitHub MCP server 才能讓 agent 讀寫 GitHub 物件；連 MCP 設定檔要注入金鑰時，也直接借用 GitHub Actions 熟悉的 ${{ secrets.VAR }}／${{ vars.VAR }} 語法。對已經在寫 workflow YAML 的 DevOps 工程師來說，這代表設定 AI agent 存取 GitHub 物件不用切換到另一套語法心智模型，也少一項要另外安裝、授權的整合項目。✅官方

但官方也把最大風險攤在陽光下：直接在 workflow step 裡呼叫 copilot 指令，對 fork PR 觸發的 CI 是公認高風險動作——外部人開的 PR 若直接觸發帶寫入權限的 Copilot CLI，等同讓不受信任的程式碼有機會碰到帶金鑰的執行環境。官方給的正解不是「小心用」，是換一個框架：GitHub Agentic Workflows——用 Markdown 寫 CI workflow，預設唯讀權限，寫入操作只能透過宣告過的 safe-outputs 通過驗證才放行；這個框架是引擎無關的（engine 欄位可選 copilot／claude／codex／gemini），不是 Copilot CLI 專屬功能。社群討論串顯示這個框架目前仍是 Technical Preview 階段，語法與行為可能還會調整，導入前務必重新核對最新官方文件。✅官方🧪未驗證

收斂成一句話：同樣是把 AI agent 接進 CI/CD，Claude Code／Codex CLI 要先解決「這把 API key 怎麼安全存放與輪替」與「GitHub 物件怎麼另外接」兩個前置工程問題，Copilot CLI 因為是 GitHub 原生血統，這兩個問題從一開始就不存在——省下的不是幾行 YAML，是一條完整的憑證管理與工具整合前置工作。

完整的指令並排對照（含 --output-format／--allowedTools／sandbox 三檔等）可以看《三大 CLI 常用指令＋工作流速查》。

場景 10：把維運工作流工程化——slash commands、hooks、CLAUDE.md 三件套

DevOps 日常是多步驟序列（看 diff → lint → 驗證 IaC → 跑測試 → commit → push），每個團隊都在重複造這些流程。👤達人個人

.claude/commands/ 目錄下每個 Markdown 檔就是一個 slash command，clone repo 的人都能用。搭配 Hooks（PostToolUse 稽核每次工具執行、Stop hook 在每輪結束自動跑 linter/formatter 並通知 Slack、PreToolUse 擋危險指令如 production 部署）與 CLAUDE.md（把技術堆疊、命名慣例、環境細節、操作規則寫成 repo 級永久記憶）、再接 MCP servers（AWS、Kubernetes、GitHub API），讓 Claude 執行實際變更而不只是生腳本。建議的導入順序是漸進式：先 PR review 指令 → 加 CLAUDE.md → 加 Stop hook 格式化 → 建完整 ship pipeline → 最後才上 MCP。

開源的 DevOps／SRE 版 CLAUDE.md 範本（FlorianBruniaux 的 devops-sre.md）涵蓋基礎設施上下文（雲商、K8s、IaC、CI/CD、服務地圖）、FIRE 事件應對框架（First Response／Investigate／Remediate／Evaluate）、安全規則（kubectl delete、scaling、terraform destroy、production DB 寫入、IAM／security group 變更一律需明確核可），核心鐵則是「任何變更前必有 rollback 計畫、環境確認（prod vs staging）、scaling 操作的影響評估」。👤達人個人

G · 伺服器維運：Ansible 與健康檢查↑ 回案例選單

場景 11：Ansible playbook 生成與除錯

手寫 playbook 的初稿建構耗時；跑掛時的錯誤（模組名錯、服務名錯、套件管理器不對）要人肉查。

實測案例（chrony／NTP）：prompt 指明目標 OS 與需求，例如「兩台 Debian 12 伺服器設定 NTP，用 Cloudflare 與 Ubuntu time servers」；Claude 生成完整 playbook，handlers 做條件式重啟、唯讀任務標 changed_when: false、用 FQCN（ansible.builtin.apt 而非裸模組名）；先跑 ansible-playbook --check dry-run 看預期變更，確認後才真跑；第二次執行 changed=0 驗證冪等性。除錯實例：playbook 在 Debian 上誤用 dnf，Claude 從 ansible facts 的 "pkg_mgr": "apt" 看出，改用泛用的 ansible.builtin.package；重啟 ntpd 失敗，查已安裝的 NTP 實作後改成 chronyd。👤達人個人

成效：初稿結構 20 分鐘壓到 2 分鐘，最大價值在「把 shell 指令序列轉成結構化 role」。可直接套用的 prompt 紀律：一定指明目標 OS；prompt 裡寫「先 --check 再真跑」；要求「並驗證服務正在執行」讓 playbook 自帶健康檢查。

場景 12：伺服器健康檢查與服務排障

日常維運雜活：SSH 上伺服器做健康巡檢、服務掛掉排障、寫 production 品質的 Dockerfile。

SSH 健康巡檢：一句 prompt 讓 Claude Code SSH 進伺服器收集 OS 版本、uptime、磁碟、記憶體、top processes、失敗服務——它自己跑 hostnamectl、uptime、df -h、systemctl --failed，回結構化報告並主動加警告。服務排障：服務掛掉時 Claude 自主診斷——查狀態 → 讀 journal → 驗證設定檔 → 找錯誤 → 修 → 驗證，「像資深 sysadmin 的工作流加速版」。Docker：寫多階段 Dockerfile（Alpine 基底、非 root 使用者、正確層快取），實測比天真單階段小 93%。

關鍵機制：Claude Code 自動繼承 shell 環境的 SSH agent、AWS 憑證、kubeconfig、Docker socket——零設定就能開工，這也是最大風險（見下方陷阱）。👤達人個人

安全設定建議：全域 ~/.claude/settings.json deny 掉 rm -rf、mkfs、curl-pipe-bash 等破壞模式；專案 .claude/settings.json（進 git，全隊生效）明確 deny terraform destroy、terraform apply -auto-approve、kubectl delete namespace；Hooks 讓改完 Terraform 檔自動跑 terraform validate、YAML 自動 lint；憑證用 aws-vault exec staging -- claude 注入短效、範圍化憑證，不用長效環境變數。不該用 Claude Code 的場合：production Terraform state 操作、金鑰輪替（用 Vault／Secrets Manager）、法遵環境（audit trail 缺口）、多租戶憑證（爆炸半徑過大）、災難復原程序（連鎖風險）。

H · 工具生態：教 Claude 慣例，而不是給它工具↑ 回案例選單

場景 13：DevOps Skills

通用 AI 生出「看似合理但違反社群慣例」的基礎設施程式碼——Skills（知識包）與 MCP（工具存取）互補：前者教最佳實務，後者讓它能動手。👤達人個人

npx skills add https://github.com/pulumi/agent-skills --skill pulumi-best-practices

推薦組合：

實測差異：沒掛 skill 的 Claude 建 S3 bucket 直接給答案；掛了之後會主動標出缺伺服器端加密、bucket policy 過寬、缺 access logging。Codex CLI 同樣有 skills 生態（放 ~/.codex/skills/ 或專案 .codex/skills/），DevOps 向有 env-doctor（環境診斷）、devsecops-expert（CI/CD／K8s／GitOps）、truth-first（改之前先驗證實際基礎設施狀態）、pre-deploy-guardian（8 階段部署前驗證）等。

I · 反面教材：terraform destroy 事故↑ 回案例選單

HN 討論的教訓：這不是 AI 特有的問題——掛著「AWS architect」頭銜但缺系統經驗的人配上不可預測的基礎設施工具，一樣會出事；預防價值在於「事故前辨識錯誤設定」的演練，不只是事後復原。這件事跟 C 節、G 節提到的 deny 清單（terraform destroy 進 settings.json 拒絕清單、CLAUDE.md 明文禁令）直接呼應——工具已經把護欄做好，事故發生在人把護欄拆了的時候。

J · Codex CLI 對照總結↑ 回案例選單

1. 定位：Codex CLI 同為終端 agent，codex 互動模式對應 claude，codex exec 對應 claude -p，AGENTS.md 對應 CLAUDE.md，codex mcp 對應 claude mcp add。
2. 權限模型差異：Codex 用 sandbox 三檔（read-only／workspace-write／danger-full-access）+ /permissions；Claude Code 用 allowedTools 白名單 + permission-mode + hooks，粒度較細，可到單一 bash 指令 pattern（如 Bash(git log *)）。
3. 維運場景官方案例：Codex 官方 cookbook 主打「CI 失敗自動修復開 PR」；Claude 官方主打「SRE 事件應對 agent」（Agent SDK cookbook）與內部團隊 K8s 排障實例。兩邊 CI 都有官方 GitHub Action（openai/codex-action@v1 與 anthropics/claude-code-action@v1）。
4. 同場景實測對比（E 節的 Terraform 審查）：Codex 強在 GitHub repo 級雲端審查與 PR 工作流；Claude Code 強在本機終端直接執行驗證工具，證據等級是「程式碼＋掃描器輸出＋驗證結果」對「程式碼分析」。
5. Codex 側陷阱：社群揭露 Codex CLI 的 TRACE 級 SQLite 日誌曾有 bug（~/.codex/logs_2.sqlite 以約 5 MB/s 寫入，估算年寫入量達 640 TB、傷 SSD 壽命），社群 workaround 是 symlink 到 tmpfs。🧪未驗證

K · 跨場景共通紀律↑ 回案例選單

把前面 13 個場景收斂成 6 條紀律，幾乎每一條都在本頁反覆出現：

L · 參考來源↑ 回案例選單

全部實際 WebFetch 開驗，標註「未逐頁開驗」者除外：