📚 课程目录第3章巡检基础

第3章巡检基础：巡检定义、巡检类型、手动 vs 自动

先聊一个挺基础、但又容易被带偏的问题：巡检到底是什么？

我的理解很简单——巡检就是「主动去检查系统是不是还健康」。跟人的体检一样，不是等肚子疼了才去医院，而是定期量血压、查血常规。我们搞告警阈值设计，得先搞清楚巡检这个动作本身。

说白了，巡检是一种周期性的、有计划的、有流程的检查行为。目标是把隐患扼杀在萌芽里。我在项目中见过很多团队把巡检等同于「看监控大盘」——嗯，这其实只是巡检的一种手段，不是全部。

巡检的三个核心要素：

巡检按检查对象分，我自己一般分成三类：

你可能会问，为什么把日志巡检单独拎出来？因为日志是「事后」和「事中」的交叉地带——日志里的异常往往比指标更早暴露问题。我自己踩过一个大坑：有一次只盯着CPU和内存，结果业务早就因为数据库连接池泄露死锁了，日志里全是大片超时堆栈，但阈值告警没配，直到用户反馈才后知后觉。

很多新手会纠结这个问题。我的观点很简单：能用自动的，就别手动；但全自动也不是万能的。

下面这张图是我自己梳理的决策逻辑，你可以当个参考：

发送告警通知手动巡检人工登录检查
结合经验判断提示：初期可手动，成熟后逐步固化到自动化脚本

为什么会这样分？核心原因是：手动巡检依赖人的经验，适合「探索性」或者「不稳定」的业务；自动巡检追求效率和一致性，适合「重复性」「确定性」的检查。

人总是会累的——检查到第30项的时候，注意力就会断崖式下降。我以前写过一份手动巡检清单，总共28项，同事每次到后半段就开始划勾了，结果漏掉两项，第二天线上出问题。
结果不可追溯——手动勾选的纸，或者聊天记录里的截图，归档起来一团乱麻。真出了问题，你都不知道上一次看日志健康检查是什么时候。
标准不统一——两个不同的人说“错误日志有点多”，一个觉得超过100行算多，另一个觉得超过10行就算多。没有阈值模板，就容易扯皮。

我曾经踩过的坑：手动巡检时只关注ERROR日志数量，忽略了WARN日志突然暴增。结果WARN日志里隐藏了某个接口的超时重试熔断，整整一周都没发现。从那以后我定了一条铁律：巡检必须包含日志级别的分布变化趋势，不只是看一个数值。

自动巡检的好处很明显：

但是代价也摆在那——自动化脚本的维护成本其实不低。就拿日志巡检来说，你要写正则解析规则、配置阈值、处理日志滚动、处理空日志文件、还要适配不同时间格式……我建议不要一上来就追求全自动，先手跑几遍，把异常边界摸清楚，再写脚本。

一个实用的小技巧：在自动巡检脚本里加一个“手动介入”的开关。遇到特殊情况（比如业务大促、版本发布），可以临时切到手动模式，让脚本只采集数据不做判断，由人来决策。等异常期过了再切回自动判断。我管这叫「半自动巡检」，既保留灵活性又不失效率。

你看，没有的好坏。我个人的习惯是这样的：在告警阈值设计的初期阶段，先用手动巡检把告警阈值调“靠谱”，再慢慢用自动巡检替代掉80%的重复劳动。剩下的20%留给人——比如判断日志里的“业务异常”和“系统异常”需要结合上下文，这就是人的优势所在。

巡检不是点一下鼠标那么简单。它分类型、分方式，本质是一个「把检查动作标准化」的过程。你掌握了手动和自动的优劣，才能为后面的阈值设计打好底。接下来我们会深入聊告警阈值的设定逻辑——不过那是后面的事了，先把今天这张图刻在脑子里。

对了，还有一句：别让巡检变成形式主义。我见过有的团队每天自动跑脚本，阈值永远不变，结果系统都扩容三次了，告警还按旧阈值叫唤——这不是巡检，是自欺欺人。

第3章 巡检基础：巡检定义、巡检类型、手动 vs 自动