📚 课程目录第3章常见巡检场景与需求分析

3. 常见巡检场景与需求分析

脚本巡检说白了就是干活。但干的是什么活？

我刚开始做运维那会儿，觉得巡检就是跑几个命令，看看CPU、内存就完事了。后来被现实狠狠教育了几次——有一次线上服务挂了，检查日志才发现磁盘早就写满了，而我每天跑的"巡检"根本没检查磁盘分区。嗯，从那以后我彻底明白了：没有需求分析的巡检脚本，就是在裸奔。

所以这一章，我们来聊聊常见的巡检场景，以及怎么从场景中提炼出真正的需求。你想想看，场景不同，需求完全不同——

这三者混在一起写脚本，那注定是两头不讨好。

我个人习惯把巡检场景分成三大类。每一类关注的东西、采集方式、输出要求都不一样。

场景类型	子场景	典型设备/对象	关注指标	采集方法
基础设施巡检	硬件、网络、电源、机房环境	服务器、交换机、UPS、空调	温度、湿度、电压、风扇转速、链路状态	SNMP、IPMI、SSH、传感器API
系统资源巡检	操作系统、中间件、数据库	Linux/Windows主机、Nginx、MySQL、Redis	CPU、内存、磁盘、进程数、连接数、慢查询	系统命令、agent、日志解析
业务应用巡检	Web服务、API、交易链路	应用服务、消息队列、负载均衡	响应时间、状态码、错误率、TPS、队列积压	HTTP请求、数据库查询、日志聚合

你看，这三大类从底层到上层，关注的东西完全不一样。我在项目中遇到过最典型的问题：团队把硬件巡检和业务巡检混写在一个脚本里，结果脚本跑了三年，硬件的PCIe错误从来没输出过——不是没发现，而是业务日志太多，硬件告警被淹没了。

我的小建议：每一类巡检做一个独立的脚本，或者至少分开模块。这样后续维护、告警分级、报告定制都清爽得多。

场景分类只是第一步。真正难的是：这个场景下到底要检查什么？说白了，就是在浩如烟海的指标里，选出那几个真正会出事的。

我一般会问自己三个问题：

举个例子，假设我们要巡检MySQL数据库——你可能会写一堆检查项：

# 错误示例：大而全但没重点
CHECK: 查询QPS
CHECK: 缓存命中率
CHECK: 连接数
CHECK: 慢查询数
CHECK: 二进制日志大小
CHECK: 表碎片率
CHECK: 主从延迟
CHECK: 死锁数
CHECK: 临时表创建量
# ...一共二十多项

但实际需要重点关注的，可能只有这几项：

# 核心检查项（很多事故都在这里起源）
CHECK: 连接数是否接近 max_connections
CHECK: 慢查询是否突然增长（对比前1小时）
CHECK: 主从延迟是否超过3秒
CHECK: 关键业务表的空间剩余是否低于阈值

  核心原则：巡检脚本不是监控面板。面板可以展示几百个指标，脚本只为"可能会出事"的指标而生。多一个指标，脚本的维护成本和误报风险就多一分。

你以为提炼完需求就结束了？太天真了。我在几个项目中摸索出一套经验，把这些痛点列出来，你最好对照着看看自己的脚本有没有踩坑。

我曾经踩过的坑：写了一个巡检磁盘的脚本，只检查了总使用率。有一次某分区使用率才30%，但inode已经满了，文件全写不进去了。从那以后，我所有磁盘检查都是"使用率+inode使用率"双指标。
教训：别只看表面指标，想想这个指标背后真正影响什么。

常见的痛点归纳如下：

痛点一：指标选择过于乐观
比如只检查CPU idle，不检查load average或CPU iowait。实际上，iowait高的时候CPU idle可能还很高，但系统已经卡死了。
痛点二：忽略基线对比
同样的CPU使用率，白天和半夜的意义完全不同。不做趋势分析、不做历史对比，等于让脚本猜天气。
痛点三：采集方式不可靠
用ps aux检查进程存在性？如果进程挂了被systemd自动拉起呢？用API检查服务状态？如果API本身也挂了呢？
痛点四：输出信息淹没在噪音中
脚本把几十个正常项和异常项混在一起打印，运维根本分不清哪个是重点。我见过一份巡检报告，500行输出只有两行是真正的告警。

为什么会出现这些问题？说白了，就是写脚本的人没有站在"使用者"的角度思考问题。你写脚本的时候，心里想的是"我要检查什么"；你应该想的是"我拿到这个输出后，怎么才能一秒看出问题"。

解决思路：写脚本前，先画一张需求流程草图。从业务场景出发，到指标提取，再到采集方式，最后落到输出格式。这张草图不需要很漂亮，但有了它，你再去写代码，思路会清晰很多。

下面这张SVG图，就是我在做需求分析时常用的框架。你可以把它当作一个"需求检查清单"——每次写新脚本前，过一遍这几层，基本不会漏项。

这张图看起来简单，但我在实际项目中一直用这套流程。打个比方，就好比你要装修房子——先想好是装厨房还是卧室（场景），再决定买什么家电（候选指标），然后挑最常用的几件（筛选），最后找人安装、拍照发朋友圈（采集和输出）。

绕开这些步骤直接写脚本，大概率会写出一个"能用但不好用"的东西。而一个"不好用"的巡检脚本，最终的下场就是被运维人员手动关闭，或者干脆没人看。

对了，还有一个细节：需求分析不是一次性的事。业务在变、架构在变、监控工具也在变。我每年会抽一个下午，把手上所有巡检脚本的需求列表过一遍，删掉过时的、补充新出现的。这个习惯救过我不少次——有一次我发现一个脚本里还检查着已经被替换掉的旧服务，数据全是空的，但之前愣是没人发现。

总结一下这一节的核心：巡检脚本的质量，80%由需求分析阶段决定。写代码只是最后的"翻译"工作。场景分清楚、指标精简化、采集可靠化、输出结构化，做到了这四点，你再去写具体的脚本，基本上不会跑偏。