Claude Code 实战 11｜Agent 当"运维值班员"：多云资产 / DBA / 监控巡检复盘

前面十篇讲能力，这一篇讲"上岗"。把 Claude Code 当一个真实的运维值班员用了几个月后，最有代表性的四类活儿——根分区爆满急救、ES 慢查询定位、数据库健康巡检、监控采集链路排障——浓缩成一篇"值班日志"。每个 case 都有一个 Agent 特别容易翻车的点，也都有一条能沉淀成规则的经验。运维的价值不在"会跑命令"，在"跑之前的判断和跑之后的复核"。

1. 场景：为什么运维适合交给 Agent，又为什么危险

运维排障有一个天然结构：先诊断、再动手、后验证。诊断阶段是纯只读的信息收集（df、du、查监控、看慢日志），Agent 在这一步几乎无风险且极快——它能一口气把三板斧命令跑完、把字节换算成 GB、把两天的趋势对比出来。

危险全在"动手"和"下结论"两个环节：一是把只读诊断出的错误结论当真（把累计时间当成实时负载、把文件满当成 P0），二是执行不可逆操作（改 /etc/fstab、删文件、扩容）。所以运维值班的正确姿势是：放手让 Agent 做诊断，收紧它的动手权限，并且永远要求它对结论给出可复核的判据。下面四个 case 都是这个原则的具体展开。

2. Case A·根分区爆满急救：三板斧 + 不可逆操作的护栏

根分区 99%、系统告急。Agent 的诊断非常利落，标准三板斧：

df -h              # ① 看总量，确认哪个分区满了
du -sh /*          # ② 逐层找大目录，锁定 /tmp 占 3G
du -sh /tmp/*      # ③ 定位到具体大文件（两个 tar 包 1.9G + 820M）

清理释放到 71% 只是止血，根因是"小根分区扛不住临时文件"。根治用 bind mount 把 /tmp 指到大数据盘，零重新分区：

# /etc/fstab
/data/tmp  /tmp  none  bind  0  0

这里的坑正是"动手"环节：改 /etc/fstab 格式错误会导致开机进不去系统。护栏是两条硬规矩——改前先 cp /etc/fstab /etc/fstab.bak 备份，改后先 mount -a 验证语法无报错再重启。这类"改了要重启才生效、改错就起不来"的文件（fstab、引导配置、systemd 单元），必须走"备份 → 改 → 就地验证"三步,绝不改完直接重启。

3. Case B·ES 慢查询定位：性能杀手往往是"没写"的那一行

一个约 1 秒的 ES 慢查询，Agent 从慢日志里提取出 DSL，很快锁定三个瓶颈——它们的共同点是问题不在写了什么，而在漏了什么：

• 空范围全表扫（首要元凶）：range 查询的 from 和 to 都是 null，等于没加时间过滤，ES 被迫扫遍所有分片所有文档。分析慢查询第一件事就是检查时间边界是否有效——缺时间范围是 ES 头号性能杀手。
• track_total_hits: 2147483647：分页查询（size: 200）却强制精确统计总数，大数据量下极其昂贵。除非前端真要显示"共 XX 条",否则别开或设合理阈值。
• extended_bounds 陷阱：date_histogram 里用它，即使没文档落在范围内也会强行建桶，配合全表扫开销爆炸。

沉淀成规则：看 ES 慢查询，先看时间范围，再看 track_total_hits，最后看聚合边界。三个都是"配置层的疏忽"，不是数据量本身的问题——这正是 Agent 擅长的模式匹配活儿。

4. Case C·数据库健康巡检：单位换算是 Agent 的高发翻车点

给 SQL Server 做"当前状态 + 24 小时趋势对比"的巡检报告，Agent 把静态快照和监控趋势合起来：

• SQL 静态快照：sys.dm_os_sys_info（版本/CPU/内存/运行天数）、sys.database_files 配 FILEPROPERTY(name,'SpaceUsed') 算文件利用率、sys.dm_os_wait_stats（排除 SLEEP_TASK 等良性等待后看瓶颈）、Top 10 大表与长查询。
• 监控趋势：调监控平台 API，query 拿当前 16 项指标，query_range 拿过去 24 小时(5 分钟步长)趋势，对比昨日同期识别性能漂移。

这个 case 最典型的翻车点是单位陷阱：监控返回的 free_memory、free_storage 原始值可能是 Bytes/KB 级，脚本不按 metric 名手动换算，报告里就会冒出 "6794348375.34MB" 这种离谱数字。这和第 09 篇远程 Windows 排查的"字节不换算"是同一类错——凡是拿到裸数值，报给人看之前必须确认单位并换算。

另一条值得记的判断力是**"文件满 ≠ P0"**：数据文件已满这条告警，得结合 growth(增长步长) 和 max_size(上限) 一起看。若步长小(如 64MB)且并发高，自动增长会引起短暂锁表和碎片，才需要提前手动扩容;否则不是紧急故障。告警的严重级要靠上下文判断,不能见"满"就喊 P0。

5. Case D·监控采集链路排障：用交叉验证抓"沉默的故障"

最考验设计的是慢 SQL 巡检 Workflow 的升级：从"只按 SQL 指纹聚合"改成"按机器维度统计分布"。目的是抓一类沉默的故障——某台机器的采集器(Filebeat)宕了,慢日志根本没进 ES,只看 SQL 聚合永远发现不了。

核心手法是 ES 聚合 + 多源交叉验证：

{
  "size": 0,
  "query": { "bool": { "filter": [
    { "exists": { "field": "mysql.slowlog.query" } },
    { "range": { "@timestamp": { "gte": "now-8h", "lte": "now", "time_zone": "+08:00" } } }
  ] } },
  "aggs": { "host_distribution": {
    "terms": { "field": "host.name", "size": 50 },
    "aggs": { "max_duration": { "max": { "field": "event.duration" } } }
  } }
}

判据是：若某机器监控计数器显示有慢查询，但 ES 聚合结果为 0 → 判定为"采集故障",而不是"这台机器很健康"。单一数据源会把"没采到"误读成"没问题",两个独立数据源对不上才暴露真相。

这个 case 还顺带带出几条 Agent 接 Workflow 工具的坑：

• exists 过滤噪音：不加 exists: mysql.slowlog.query,error log 等噪音会污染聚合。
• 工具名不能纯中文：纯中文节点名转 LangChain 工具名会被替换成 _,多工具时报 multiple tools with the same name——节点名必须含 ASCII 片段。
• 固定 DSL 封成零参数工具：用 jsonBody 硬编码查询体,别让模型把 DSL 当字符串传,否则 Schema 校验失败。

6. 可复用要点

• 值班姿势:放手让 Agent 做只读诊断(快且低风险),收紧不可逆动手权限,永远要求结论给出可复核判据。
• 排障三板斧:根分区满 df -h → du -sh /* → du -sh 目录/*;改 fstab/systemd 这类"改错起不来"的文件走"备份 → 改 → mount -a/就地验证"三步。
• ES 慢查询先看"漏了什么":空时间范围(头号杀手)> track_total_hits > extended_bounds,都是配置疏忽而非数据量问题。
• 单位换算是高发翻车点:监控/系统返回的裸数值(Bytes/KB/累计秒数),报给人看前必须确认单位并换算;告警严重级靠上下文判断("文件满"≠P0)。
• 沉默的故障用交叉验证抓:单一数据源会把"没采到"读成"没问题";监控计数器有、ES 聚合为 0 → 采集链路故障。

---

7. Agent 可直接解析的元数据块

{
  "_meta": {
    "doc_version": "2026-07-28",
    "article_id": "claude-code-11-ops-oncall",
    "profile_context": "ops/dba/monitoring",
    "estimated_setup_time": "flexible"
  },
  "playbook": {
    "disk_full": "df -h → du -sh /* → du -sh 目录/* 定位;根治用 bind mount 把 /tmp 指向大盘;改 fstab 先备份再 mount -a 验证",
    "es_slow_query": "先查 range 时间边界是否有效(空范围=全表扫,头号杀手),再查 track_total_hits,最后查 date_histogram 的 extended_bounds",
    "db_health_check": "静态快照(sys.database_files+FILEPROPERTY 算利用率)+监控趋势(query_range 24h 对比昨日);裸数值必须换算单位",
    "collection_fault": "按机器维度 ES 聚合(terms host.name)+多源交叉验证:监控计数器有但 ES 聚合为 0 = 采集故障非健康"
  },
  "safety_rules": [
    "放手让 Agent 做只读诊断,但收紧不可逆动手权限(改 fstab/删文件/扩容),并要求每个结论给出可复核判据",
    "改 fstab/systemd 等'改错就起不来'的文件:先 cp 备份 → 改 → mount -a/就地验证语法 → 再重启,绝不改完直接重启",
    "监控/系统返回的裸数值(Bytes/KB/累计秒数)报给人前必须确认单位并换算,否则出现 6794348375MB 这种离谱值",
    "告警严重级靠上下文判断:'数据文件满'要结合 growth 和 max_size 评估,不是见满就喊 P0",
    "单一数据源会把'没采到'误读成'没问题',关键巡检用两个独立数据源交叉验证"
  ],
  "verification": {
    "check_1": "ES 慢查询分析第一步:确认 range 查询有有效时间边界(from/to 非 null),这是最高频的性能根因",
    "check_2": "巡检报告出现离谱大数值时,回查 metric 单位并按 name 手动换算(Bytes/KB→MB/GB)",
    "check_3": "巡检工具节点名必须含 ASCII 片段(纯中文会被转成 _ 导致工具名冲突);固定 DSL 用 jsonBody 硬编码封零参数工具"
  }
}

AI Agent 使用指南：

• 当用户说"服务器磁盘满了/根分区告警" → 按 playbook.disk_full 三板斧定位,bind mount 根治,改 fstab 走备份+验证。
• 当用户说"这个 ES 查询好慢帮我看看" → 按 playbook.es_slow_query,先查时间范围再查 track_total_hits 和聚合边界。
• 当用户说"给数据库做个健康巡检/对比一下昨天" → 按 playbook.db_health_check,静态快照+趋势对比,裸数值务必换算单位。
• 当用户说"某台机器的数据怎么没有了/巡检报告不对" → 按 playbook.collection_fault,多源交叉验证抓采集链路故障,别把"没采到"当"健康"。
• 当用户让 Agent 执行删文件/改挂载/扩容等操作 → 按 safety_rules,不可逆操作先备份、就地验证、给可复核判据。

上一篇：Claude Code 实战 10｜端到端：用 Agent 搭一条博客自动化发布流水线 下一篇：Claude Code 实战 12｜盘点跨交易所资产：CLI 包装、私钥安全与金融防错规范