体检脚本的通病：写完就没人看了

体检脚本的通病：写完就没人看了

做过运维的人大概都写过巡检脚本：磁盘用量、内存占用、进程存活、证书到期时间，几十项检查跑一遍，输出几十行文本。第一周自己看两眼，第二周就再也没人打开了。原因很简单——脚本把"所有信息"平等地倒给你，等于什么重点都没说。

真正"人愿意长期看"的体检脚本，核心不是检查项多，而是让人在三十秒内做出"今天要不要处理"的判断。

输出设计：先给结论，再给证据

把输出分成三层，阅读顺序由上到下，信息密度由重到轻：

• 第一层：一句话摘要。类似"3 项告警 / 2 项警告 / 51 项正常"，用颜色区分。人打开终端第一眼扫到摘要，有告警才往下看。
• 第二层：异常项展开。只列出非正常的条目，每项带上当前值、阈值、影响范围。正常项全部折叠，不占屏幕。
• 第三层：全量明细。加 --verbose 参数才输出。日常巡检根本不需要，只有排查问题时才展开。

具体实现上，摘要行用 printf 配合 ANSI 颜色码，异常项按严重程度排序，同级别的按检查名字典序。不要按脚本里检查项的书写顺序输出——那个顺序只有你自己能看懂。

检查项的元信息：让脚本自己描述自己

早期我写检查逻辑就是一串 if-else，维护半年后自己都记不清第 17 项是干什么的。后来改成每个检查项声明一个元信息块：

check_disk: { name: "系统盘空间", unit: "%used", warn: 80, crit: 95, owner: "infra", doc: "df -h /" }

好处有三个。第一，输出时自动带上 owner 和 doc，看报告的人知道找谁、用什么命令复现。第二，加新检查项只需要填一个结构体，不用改输出逻辑。第三，阈值和逻辑分离，调阈值改配置不改代码，运维同事也敢动手。

可维护性：拒绝"能跑就行"

几个血泪教训：

• 所有外部命令用 timeout 包裹。一次 kubectl get nodes 卡住能拖死整个巡检。
• 检查项之间必须相互独立。某项因为服务未部署而失败，不应阻断后续检查。用 || true 或显式捕获退出码。
• 输出同时支持终端和管道。终端下带颜色，重定向到文件时自动去 ANSI 码（检测 [ -t 1 ]）。否则日志文件里全是 \033[31m。
• 退出码做约定：0 全正常，1 有警告，2 有严重告警。这样 CI 或者外部调度器能直接消费。

最后一个习惯：把体检结果变成可追踪的历史

脚本跑完把摘要行追加到一个 CSV 或者写入 Prometheus PushGateway。单次的巡检输出看完就忘，但趋势图会逼你面对问题——磁盘从 60% 涨到 78% 用了三周，这个信息比任何单次告警都有说服力。做到这一步之后，团队开会时会主动说"先拉一下最近的巡检趋势"，脚本才真正活了下来。