DevOps 运维中 AI 那些事

这两年运维群里最常见的一类对话是：贴一段报错，问谁看得懂。以前碰到这种问题，我要翻文档、翻历史工单、翻 Prometheus，运气不好还得翻半年前的变更记录。现在大家的第一反应是丢给模型。

用得好的团队，AI 已经不只是个聊天框了。用得不好的，它就是一个会一本正经编造参数的高级输入法。

这篇把我在服务器硬件、虚拟化、Kubernetes、CI/CD、可观测性、资源分配，以及"反过来给 AI 自己搭环境"这几个环节里，实际让 AI 干过的事、能干的事、以及踩过的坑，整理一遍。不讲概念，讲活。

#一、先把边界划清楚

AI 在运维里能站的位置，我习惯分三档：

只读顾问。 给只读账号、只读 API，只输出分析和建议。这一档最安全，也最容易起步。

变更起草。 产出 diff、YAML、脚本，但必须走正常评审。人还是审批人。

自动执行。 只限于幂等、可回滚、影响面可控的动作，比如调整副本数、重启某个无状态 Deployment、清理过期镜像。即便如此，也要白名单加审计。

三条红线我自己一直守着：不直接给它生产写权限；不让它碰密钥和凭据；它给的每条命令、每个参数，都要能验证。第三条最容易被忽略——运维场景里幻觉的代价不是"答错了"，是"改炸了"。

有个简单的判断标准：这条命令你不敢在评审会上念出来，就别让它自动执行。

#二、硬件层：服务器、网络、显卡、内存

#1. 服务器与带外

硬件这件事，AI 最擅长的不是"知道"，而是"整理"。

把 dmidecode、lspci -nn、ipmitool sel elist、numactl --hardware 的输出一起丢过去，让它产出硬件清单、NUMA 拓扑、槽位分布、以及可疑点。这类事人做要半小时，还容易漏。

# 巡检信息一次收齐
lspci -nn | grep -Ei 'nvidia|ethernet|infiniband|raid|nvme'
dmidecode -t system -t memory -t processor | head -100
ipmitool sel elist | tail -50
ipmitool sensor list | grep -Ei 'temp|fan|psu|power'
numactl --hardware

具体能干的活：

• SEL 日志归类。 几百行 SEL 里哪些是真故障、哪些是插拔和重启产生的噪音，让它先分一遍。
• 故障预测。 SMART 属性、EDAC 的 CE/UE 计数、MCE 日志，让它看趋势并指出哪块盘、哪条内存该重点关注。
• RAID 状态解读。 storcli / perccli 的输出很反人类，让它翻译成"几号盘、什么状态、重建进度、下一步动作"。
• 固件与驱动版本矩阵。 这个特别费人。服务器型号、BIOS、BMC、NIC 固件、驱动、CUDA 版本之间的兼容关系，模型能给个初稿，但必须拿厂商兼容列表交叉验证——它经常把不同代际的参数混在一起，说得还很确定。
• 验收清单生成。 上架、扩容、换件之后的检查项，让它按你的机型生成一份 checklist，比凭记忆靠谱。

#2. 网络

网络是 AI 收益很高、也很容易翻车的一块。

能干的：

• 配置起草与审阅。 交换机配置、BGP/OSPF 策略、ACL、iptables/nftables 规则，让它写初稿，也让它审初稿。
• 变更前的差异分析。 把变更前后两份配置 diff 加上一句意图描述（"我要放行 10.20.0.0/16 到数据库段的 5432"），让它找会不会误伤。这一步我觉得是性价比最高的用法。
• 故障定位的思路。 mtr、traceroute、tcpdump 结果、交换机端口计数、丢包位置，让它给出下一步该查什么。
• 地址与 VLAN 规划。 给它现有网段，让它排新分配，顺便指出冲突和掩码问题。

翻车的地方：厂商私有 CLI 差异太大。 H3C、华为、锐捷、Cisco 的语法经常被混着用。所以 prompt 里必须锁死厂商、型号、软件版本，最好直接贴一份现网配置当 style 参考。

#3. GPU 与算力

GPU 这块是最近两年运维新增的大头，也是 AI 最能帮上忙的地方，因为报错信息普遍很晦涩。

• Xid 错误解读。 dmesg 里的 NVRM: Xid (PCI:0000:xx:00.0): 79, pid=..., GPU has fallen off the bus 这种，让它解释可能原因和排查顺序，比自己翻 NVIDIA 文档快。
• ECC 与掉卡。 统计 ECC 错误计数、判断是否需要 RMA、是否需要 reset GPU。
• 性能瓶颈定位。 把 nvidia-smi topo -m、dcgmi diag、nvidia-smi dmon 的输出丢过去，让它结合 NVLink 拓扑、PCIe 代际与宽度、NUMA 亲和性，判断跨卡访问是不是瓶颈。
• 多机训练的通信问题。 NCCL 报错、IB/RoCE 的 PFC/ECN 配置、链路速率协商不上，让它核对配置一致性。
• 算力切分选型。 MIG、time-slicing、MPS 各适合什么场景，让我省了不少试错。
• 利用率盘点。 哪些卡长期空转、哪些任务显存申请严重超出实际使用，这类报告让它定期出一份。

之前写过 H200 服务器和 vLLM 部署的两篇，硬件拓扑和并行策略的细节在那里，这篇不重复。

#4. 内存

内存问题人肉查很痛苦，因为要同时看内核、cgroup、应用运行时三层。

• OOM 分析。 dmesg 里的 oom-killer 输出、/sys/fs/cgroup/memory.events、容器 OOMKilled 事件，让它判断到底是宿主 OOM 还是 cgroup limit 触发，是谁先被杀。
• 泄漏判断。 slab、PageTables、anon、file cache 的增长趋势，配合 numastat、cat /proc/meminfo 多采样几次，让它看是哪一块在长。
• 运行时参数。 JVM 的 GC 日志、Go 的 pprof、Python 的内存增长，让它给排查路径和参数建议。
• 硬件层面。 EDAC 的 CE 计数持续上涨，基本就是内存条要挂了，让它盯着趋势并定位到具体通道和槽位。

注意一点：模型给的运行时参数数值（比如堆大小、GOGC、max-old-space-size）经常是"合理但不适合你"的，必须结合自己的实际负载再确认一遍。

#三、虚拟化层

跑 KVM/libvirt 的环境，日常的活大量是重复的，AI 在这里很省时间。

• XML 起草与审阅。 CPU pinning、NUMA 绑定、hugepage、virtio 参数、iothread、cache mode，让它写初稿，也让它审现有 XML 里有没有明显不合理的地方。
• 性能问题排查。 CPU steal time 高、IO 延迟抖动、磁盘调度器和 cache 模式选错、virtio 队列数不够，这类问题把 virsh domstats、iostat -x 1、宿主 top 一起给它，定位效率比自己翻高。
• 存储链路。 qcow2 链过长、快照合并、Ceph/iSCSI 链路抖动，让它梳理排查顺序。
• 批量运维脚本。 巡检、批量改配置、批量开关机，让它写脚本——但要求带 dry-run 模式和逐机确认，不然一次手滑就是几十台。
• 容量与超卖。 给它各虚拟机的实际用量（不是申请量），算合理超卖比，指出哪台宿主机该迁移了。
• 迁移方案草稿。 VMware 转 KVM、磁盘格式转换、网络映射，让它出方案框架，细节自己补。

虚拟化的坑在于环境差异大，它的通用建议经常和你实际的 libvirt/QEMU 版本对不上。贴版本。

#四、Kubernetes

#1. 组件与架构

• 组件交互梳理。 apiserver、etcd、scheduler、kubelet、controller-manager，加上 CNI/CSI/CRI 各在什么环节介入。让它画成调用链讲一遍，适合做团队内部文档的底稿。
• 架构评审。 把你的集群拓扑、节点分布、控制面部署方式、存储与网络方案丢进去，让它按失效域、单点、升级影响面挑刺。它挑出来的东西不一定都对，但能提醒你漏掉的维度。
• 版本升级。 release notes 摘要、废弃 API 检查（pluto / kubent 的输出解读）、升级顺序和回滚预案，让它起草。
• 网络方案选型。 Calico 与 Cilium 的 eBGP 模式、隧道与直接路由、NetworkPolicy 在两种实现下的行为差异，让它做对比表格，但结论要自己验证。

#2. 应用编排

• YAML 起草。 Deployment/StatefulSet/CronJob 的完整骨架：resources、探针、PDB、反亲和、拓扑分布约束、安全上下文。让它一次写全，比从旧文件复制粘贴少漏东西。
• 现有 YAML review。 这一项我常用，效果好。让它找出：没设 resources、探针过于激进（失败阈值太低导致滚动更新卡死）、单副本、镜像用 latest、权限给太宽、缺 PodDisruptionBudget。
• Helm values 多环境管理。 环境差异怎么组织、哪些该抽成 values、哪些不该，让它给结构建议。

#3. 排错

K8s 排错的难点不是知识，是信息分散。AI 的真正价值在这里。

标准做法是先把信息收齐，再一起给它：

kubectl get pod -n <ns> -o wide
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -30
kubectl describe node <node> | grep -A5 Allocated

然后让它按"现象 → 可能原因（按概率排序）→ 每条的验证命令"输出。常见场景它都处理得不错：Pending（调度失败原因在 events 里）、CrashLoopBackOff、OOMKilled、ImagePullBackOff、PVC 绑定失败、DNS 解析不通、NetworkPolicy 拦截。

但要注意： etcd 慢、apiserver 限流、CNI 数据面异常这类问题，它给的结论普遍偏浅，动不动就"检查网络""重启 kubelet"。这种时候还得自己看 metrics。

#五、应用构建与 CI/CD

• Dockerfile 优化。 多阶段构建、层缓存顺序、镜像瘦身、非 root 用户、.dockerignore。把现有 Dockerfile 丢过去让它改，一般能砍掉不少体积。
• 构建失败定位。 编译日志动辄几千行，真正的第一个错误可能埋在第 200 行。让它找"第一个真正的错误"而不是最后一条报错——这个活它做的比人快很多。
• 依赖问题。 版本冲突、lock 文件、私有源配置、跨平台构建失败。
• 流水线起草与优化。 GitHub Actions、GitLab CI、Jenkins、Argo Workflows 的 YAML，缓存策略、并发控制、矩阵构建、构建机资源分配。
• 失败分类。 让它把近期流水线失败归类：代码问题、环境问题、flaky test、资源不足。分类清楚之后才知道该修什么。
• 变更风险评估。 把 PR diff 和受影响的模块列表给它，让它列可能影响面和回滚点，作为评审参考。
• Release note 与 changelog。 从 commit 记录生成，人工润色。这个最省心。

#六、可观测性：监控、日志、链路、告警

#指标

PromQL 和 LogQL 生成是我用得最高频的功能。用自然语言描述"过去一小时 5xx 比例超过 1% 的服务，按 namespace 聚合"，它基本能一次写对，写不对也能在 Prometheus 里马上验证。

#日志

• 异常聚类。 几万行错误日志压成几类，每类给代表样本和可能原因。
• 时间线重建。 把多个组件的日志按时间对齐，还原故障过程。

注意：全量日志丢给模型成本很高。先过滤、采样、脱敏，再喂。

#链路

把 Jaeger/Tempo 的 trace 结构丢过去，让它指出慢在哪一段、是串行调用可以并行、还是某次 DB 查询缺索引。

#告警

三件事：

1. 规则审阅。 现有告警规则里阈值是否合理、有没有覆盖关键路径、会不会在节点重启时产生风暴。
2. 降噪。 抖动告警、重复告警、父子告警的抑制关系。让它按服务依赖给抑制规则建议。
3. 触发后的上下文聚合。 告警响的时候，自动把相关面板、最近变更、相关日志、历史同类故障拉到一起。这一项是最能缩短 MTTR 的，因为值班的人最耗时间的不是分析，是找信息。

有个前提要说清楚：SLO 得业务来定，别让 AI 替你定。 它能帮你把 SLO 翻译成告警规则，但"用户能接受多久不可用"这件事它不知道。

#七、资源分配与成本

• requests/limits 建议。 基于历史用量给 p95/p99，而不是拍脑袋。让它按"先给 p95 requests，limits 放宽 1.5 到 2 倍"这类规则批量生成，再人工过一遍。
• 闲置回收。 长期低用量的 namespace、无人挂载的 PV、空转的负载均衡、过期快照、停着的测试机。让它定期扫一遍出清单。
• 容量预测。 按增长趋势算什么时候该加机器、加多少。
• 分层调度。 在线/离线混部、抢占策略、GPU 池化。让它给调度策略草稿。
• 成本拆分。 账单按团队、项目、环境拆开，找出大头在哪。

提醒一句：缩容建议一定要留安全边界。 按平均值压到极限，平时没事，流量一冲就雪崩。留出至少一倍余量。

#八、反过来了：AI 自身的部署与算力

这是运维这两年新增的活，而且量不小。

推理服务部署。 vLLM、SGLang、TensorRT-LLM、TGI，各有各的参数体系。max-num-seqs、gpu-memory-utilization、max-model-len、tensor-parallel-size、enable-prefix-caching 这些参数怎么配，取决于模型大小、卡数、显存和预期的并发。让它解释参数含义和相互影响可以，但最终值必须压测出来。

K8s 上的编排。

• GPU 调度：device plugin、节点标签与污点、GPU 共享策略
• 权重管理：PVC、对象存储、还是直接打进镜像（几十 GB 的镜像，拉一次想死）
• 服务编排：Deployment 还是 LeaderWorkerSet / Job，多机推理的 pod 拓扑
• 弹性：按队列长度扩缩容，冷启动动辄几分钟，扩容策略要提前考虑

算力切分。 MIG 适合隔离要求高、模型小的场景；time-slicing 适合开发测试环境多任务共享；MPS 介于两者之间。选错了要么浪费显存，要么任务互相拖慢。

多机并行策略。 TP、PP、EP 怎么选，取决于模型结构、卡间互联（NVLink 还是跨机 IB）和 batch 形态。让它给初稿，实测校准。

网关与配额。 限流、按团队配额、Token 计费、多模型路由、灰度。这层通常用 AI Gateway 类产品，但规则还是得自己定。

监控要看对指标。 GPU utilization 是个很骗人的数字：显存占满了但计算单元空转，利用率照样显示很高。真正该看的是显存占用、等待队列长度、TTFT、TPOT、输出 token 吞吐、以及 KV cache 命中率。

私有化与数据安全。 Embedding 服务、向量库、RAG 链路，模型权重和数据的访问控制。这块是合规红线，别图省事用公共 API 处理内网日志。

#九、怎么落地：一条渐进路径

阶段一（一到两周）：只读。 只接日志、配置、监控数据，只做分析和解释。不给任何写权限。这一阶段的目标是让团队建立"哪些问题问它有用"的直觉。

阶段二：起草。 让它产出 diff、YAML、脚本，走现有评审流程。这一阶段要统计采纳率——如果采纳率低于一半，说明 prompt 或者场景选错了，别急着往下走。

阶段三：受限自动执行。 选三五个低风险动作，白名单 + 审批 + 完整审计日志。每自动执行一次都要能事后复盘。

阶段四：闭环。 告警触发后自动收集上下文、生成诊断、给出处置建议，部分场景自动恢复。

每一阶段都要保证：可回滚、有审计、人能随时接管。跳步骤直接上自动执行的团队，我见到的基本都吃过亏。

#十、坑

最后列几个真实踩过的：

• 幻觉。 编造参数名、编造指标名、编造 CRD 字段。它给的字段在文档里查不到，那就是编的。
• 上下文污染。 长对话里前面一个错误结论会被反复引用强化。重要问题开新会话，别怕麻烦。
• 版本漂移。 它不知道你线上跑的是什么版本。每次都把版本号写进 prompt。
• 权限蔓延。 一开始只读，后来图省事给了写权限，再后来就是事故。权限要收，不要放。
• 数据外泄。 日志里有 token、内网地址、用户信息。要么私有化部署，要么先脱敏。
• 成本失控。 让它跑全量日志，账单会教你做人。
• 技能退化。 新人不再读文档，只会问 AI，遇到它没见过的问题就完全没思路。这个比技术风险更长期。
• 最危险的是"看起来对"的答案。 一眼假的东西你会去查，看起来合理的你会直接用。

#写在最后

别一上来就搞平台、搞 Agent、搞自动化闭环。

先找你日常最耗时的那个环节——我的判断对多数团队来说是"故障发生时的信息收集"和"配置变更前的检查"——把 AI 接进去，用两周，量一下是不是真的省了时间。省了再往下走，没省就换个场景试。

工具是要算投入产出的，AI 也一样。