OS 运维 Skills：凌晨两点的排查交给 Agent
OS 运维 Skills 是什么？
一句话：让任何运维 Agent 具备资深内核专家的诊断能力。
不需要你记得住：
- eBPF 探针怎么挂
- 内核调用栈怎么看
- cgroup 内存统计怎么算
Agent 通过 Skill 融合分析：
- 监控数据
- 日志数据
- 探针数据
完成：
- 数据采集
- 因果归因
- 修复决策
几分钟返回完整根因链和修复方案。
这是运维工作模式的结构性变化
不是某个监控指标的改善。
是运维工作模式的结构性变化。
旧范式：工程师是侦探
凌晨两点，告警响了。
第一步：工程师接到告警
[ALERT] High memory usage on server-10第二步：打开 Grafana/Prometheus 看面板
- 内存使用率 85%
- 没有明显趋势
- 不知道是哪个进程
第三步：SSH 登录机器，逐个跑命令排查
top
ps aux
free -h
cat /proc/meminfo第四步：靠经验交叉比对，拼凑因果链
- 看起来是 Java 进程占用高
- 但 Java 进程有好几个
- 不知道是哪个
- 也不知道为什么占用高
第五步：人工判断修复方案
- 重启？
- 扩容？
- 调参数？
- 不确定哪个对
新范式：Agent 是诊断专家
同样的告警，Agent 接手。
第一步：Agent 接收告警
[ALERT] High memory usage on server-10第二步：Agent 调用诊断 Skill
正在加载 OS 运维诊断 Skill...第三步：Skill 告诉 Agent 需要怎么排查问题
Skill 指引：
1. 检查 cgroup 内存统计（确认是容器/进程级别）
2. 挂载 eBPF 探针（追踪内存分配调用栈）
3. 抓取内核调用栈（确认内存泄漏路径）
4. 分析 slab 分配器（确认内核对象泄漏）第四步：Agent 自动完成数据收集和根因分析
数据收集：
✅ cgroup memory.stat: rss_anon 4.2GB
✅ eBPF: 大量 malloc 在 java/lang/String.intern
✅ 内核调用栈: String.intern → native → strdup
✅ slab: dentry cache 正常
根因分析：
✅ 应用代码频繁调用 String.intern()
✅ 字符串池持续增长，无法 GC
✅ 确认：应用级内存泄漏第五步：Agent 输出修复建议
修复方案：
1. 短期：重启 pod（立即缓解）
2. 中期：找到调用 String.intern() 的代码
3. 长期：替换为 WeakHashMap 或 LRU cache
优先级：P0（影响线上服务）
预计恢复时间：5 分钟（重启）→ 2 天（代码修复）工程师的角色转变
旧角色：侦探
你在凌晨两点：
- 手动跑命令
- 交叉比对数据
- 拼凑因果链
- 靠经验猜测
新角色：架构师
你在任何时候：
- 审阅诊断报告
- 理解根因链
- 决策修复策略
- 评估风险和收益
Skill 到底做了什么？
Skill 不是监控工具。
Skill 是诊断方法论。
第 1 层：数据采集
Skill 告诉 Agent：
| 问题 | Skill 指引 |
|---|---|
| 内存问题 | 检查 cgroup 统计 → eBPF 追踪分配 → slab 分析 |
| CPU 问题 | perf 采样 → 火焰图 → 调度延迟分析 |
| 磁盘问题 | iostat → blktrace → 延迟分布 |
| 网络问题 | tcpdump → eBPF 网络追踪 → 连接跟踪 |
Agent 不需要记住这些命令。
Skill 告诉它什么时候用什么。
第 2 层：因果归因
Skill 告诉 Agent：
| 现象 | 可能根因 | 验证方法 |
|---|---|---|
| 内存高 | 应用泄漏 vs 内核泄漏 | cgroup rss vs slab |
| CPU 高 | 用户态 vs 内核态 | perf 采样 |
| 磁盘慢 | IO 瓶颈 vs 文件系统瓶颈 | iostat vs blktrace |
| 网络抖动 | 丢包 vs 重传 vs RTT | tcp 统计 vs eBPF |
Agent 不需要积累经验。
Skill 告诉它怎么验证。
第 3 层：修复决策
Skill 告诉 Agent：
| 根因 | 短期 | 中期 | 长期 |
|---|---|---|---|
| 应用内存泄漏 | 重启 | 找泄漏点 | 修复代码 |
| 内核内存泄漏 | 升级内核 | 报 bug | 优化配置 |
| 配置不当 | 调参数 | 更新文档 | 添加监控 |
| 容量不足 | 扩容 | 预测容量 | 自动伸缩 |
Agent 不需要拍脑袋。
Skill 告诉它标准修复路径。
为什么需要 Skill？
问题 1：运维知识太深
- 内核参数：几百个
- eBPF 探针：上千个
- 系统调用：几百个
- 性能工具：几十个
一个人很难全部记住。
Skill 把这些知识编码成方法论。
问题 2：排查路径太多
内存问题可能来自：
- 应用泄漏
- 内核泄漏
- 配置不当
- 容量不足
- 外部依赖
没有经验的人不知道选哪条路。
Skill 给出标准排查路径。
问题 3：凌晨二点的决策不靠谱
你很累：
- 容易误判
- 容易漏掉关键检查
- 容易选错修复方案
Skill 不累。
Skill 每次都按同样的步骤排查。
具体场景示例
场景 1：内存泄漏告警
告警： Memory usage > 85% on server-10
Agent 执行：
Step 1: 检查 cgroup
→ rss_anon 4.2GB（应用内存）
→ file 0.5GB（文件缓存）
→ slab 0.3GB（内核对象）
Step 2: eBPF 追踪分配
→ 大量 malloc 在 java/lang/String.intern
→ 每秒 1000+ 次
Step 3: 验证
→ String.intern() 调用无法 GC
→ 确认：应用级内存泄漏
Step 4: 修复方案
→ 短期：重启 pod
→ 中期：找到调用代码
→ 长期：替换为 WeakHashMap你只需要：
- 审阅报告
- 批准重启
- 指派开发修复
场景 2：CPU 突然飙升
告警： CPU usage > 90% on server-20
Agent 执行：
Step 1: perf 采样
→ 80% 在内核态
→ 主要是 do_syscall_2
Step 2: eBPF 追踪系统调用
→ 大量 futex_wait
→ 线程锁竞争
Step 3: 验证
→ Java 应用线程数 2000+
→ 锁等待时间 > 50%
Step 4: 修复方案
→ 短期：重启（缓解）
→ 中期：调整线程池配置
→ 长期：重构锁逻辑你只需要：
- 理解根因（锁竞争）
- 批准配置调整
- 指派性能优化
场景 3：磁盘延迟飙升
告警： Disk latency > 100ms on server-30
Agent 执行：
Step 1: iostat
→ await 120ms
→ %util 100%
Step 2: blktrace
→ 大量随机写
→ 块大小 4KB
Step 3: 验证
→ MySQL InnoDB 刷盘
→ innodb_flush_log_at_trx_commit = 1
→ 每个事务同步刷盘
Step 4: 修复方案
→ 短期：调为 2（每秒刷一次）
→ 中期：增加 buffer pool
→ 长期：迁移到 SSD你只需要：
- 理解根因（配置保守）
- 批准参数调整
- 评估迁移计划
工程师的一天：旧 vs 新
旧范式：
09:00 到公司，查看夜间告警
10:00 昨晚的告警还在排查
12:00 还没定位根因
14:00 终于找到根因，不确定修复方案
16:00 尝试修复，观察效果
18:00 还没解决，加班
20:00 还在查日志
22:00 终于解决，精疲力尽新范式：
09:00 到公司，查看夜间告警
09:05 Agent 已给出根因和修复方案
09:10 审阅报告，批准修复
09:15 修复已部署
09:20 验证效果，继续其他工作Skill 的价值
价值 1：速度
旧： 几小时到几天 新： 几分钟
价值 2：准确性
旧： 靠经验，容易误判 新： 标准流程，每步验证
价值 3：可复制
旧： 经验在少数专家脑子里 新： Skill 可以复制到任何 Agent
价值 4：不累
旧： 凌晨两点排查，容易出错 新： Agent 不睡觉，每次都一样
写在最后：从侦探到架构师
OS 运维 Skills 不是工具。
OS 运维 Skills 是范式转变。
旧范式：
工程师 = 侦探
- 收集线索
- 交叉比对
- 拼凑因果链
- 靠经验破案
新范式：
工程师 = 架构师
- 审阅诊断报告
- 理解根因链
- 决策修复策略
- 评估风险和收益
这不是某个监控指标的改善。
这是运维工作模式的结构性变化。
OS 运维 Skills 让任何 Agent：
- 不需要记住 eBPF 探针怎么挂
- 不需要记住内核调用栈怎么看
- 不需要记住 cgroup 统计怎么算
它只需要：
- 加载 Skill
- 按指引采集数据
- 按流程分析根因
- 按标准输出修复方案
凌晨二点的告警？
交给 Agent。
你做架构决策。
这就是 OS 运维 Skills 的价值。
让工程师从「凌晨两点手动拼线索的侦探」，变成「审阅诊断报告、决策修复策略的架构师」。
"