4. 巡检周期与策略：巡检频率设计、不同场景的巡检策略、定时巡检与触发式巡检
巡检这事儿，说白了就是跟系统故障赛跑。跑得太勤，运维累死，资源也浪费；跑得太少，故障来了你还在睡大觉。我这些年踩过的坑告诉我——巡检周期设计，从来不是拍脑袋定个“每天一次”就完事的。
4.1 巡检频率设计：别让机器闲着，也别让人累着
我个人习惯把巡检频率分成三个梯队：
| 梯队 | 频率 | 适用场景 |
|---|---|---|
| 高频 | 每5~15分钟 | 核心业务、数据库、网络出口 |
| 中频 | 每小时~每4小时 | 应用服务、中间件、存储 |
| 低频 | 每天~每周 | 日志清理、证书过期、磁盘碎片 |
你想想看，一个电商网站的核心交易链路，你敢让它15分钟才查一次吗？我遇到过一家公司，数据库连接池的巡检频率设成了1小时一次。结果高峰期连接池被打满，整整45分钟没人发现——嗯，那个值班的兄弟后来被请去喝茶了。
4.2 不同场景的巡检策略：一把钥匙开一把锁
不同场景，策略完全不同。我总结了几种典型场景：
4.2.1 核心交易系统
- 策略：全链路巡检 + 黄金指标监控
- 频率：1分钟级
- 重点：响应时间、错误率、吞吐量、队列深度
我记得有一次帮一家银行做巡检设计，他们要求“交易失败必须在30秒内感知”。最后我们用了触发式巡检——每次交易失败时，立即触发一次深度巡检，把当时的系统状态全部dump下来。这招帮他们定位了好几个隐蔽的bug。
4.2.2 非核心业务系统
- 策略：基础指标巡检 + 日志异常扫描
- 频率：15~30分钟
- 重点：CPU、内存、磁盘、进程存活
说白了，这类系统挂了也不会死人，但也不能让它一直挂。我一般建议用定时巡检兜底，再加一个简单的健康检查接口。
4.2.3 基础设施层（网络、存储、电源）
- 策略：SNMP轮询 + 硬件告警
- 频率：5~10分钟
- 重点：端口状态、光功率、温度、风扇转速
4.3 定时巡检与触发式巡检：两条腿走路
这两种方式不是二选一，而是互补的。我画了一张图来说明它们的关系：
4.3.1 定时巡检：稳扎稳打
定时巡检就像每天的体检——不管你有没有病，该查的都查一遍。它的好处是：
- 可预测：你知道它什么时候跑，资源占用可控
- 全覆盖：不会漏掉任何指标
- 好追溯：每次结果都能对比，趋势分析就靠它
但定时巡检有个硬伤——它不知道什么时候该“加钟”。比如磁盘使用率从60%涨到80%，定时巡检可能4小时后才发现。这中间要是出了事，谁来背锅？
4.3.2 触发式巡检：精准打击
触发式巡检就不一样了。它是“有事才查，没事不扰”。常见的触发条件：
- 阈值触发：CPU > 90%、内存 > 85%、磁盘IO等待 > 50ms
- 事件触发：进程重启、服务降级、网络闪断
- 日志触发：ERROR级别日志出现、特定关键字匹配
- 人工触发：运维人员手动发起深度巡检
4.3.3 两者如何配合？
我见过最好的实践是这样的：
- 定时巡检负责“日常巡逻”，采集全量数据，生成趋势报告
- 触发式巡检负责“应急响应”，一旦发现异常，立即执行深度检查
- 两者共享同一个告警通道，但触发式巡检的优先级更高
举个例子：定时巡检发现某台服务器的磁盘IO延迟从10ms涨到了30ms。这时候它不会直接告警，而是触发一次IO深度巡检——检查是哪个进程在搞鬼、磁盘是否有坏道、RAID卡是否报错。等深度巡检结果出来，再决定是否告警。这招我称之为“先查后报”，能减少至少60%的无效告警。
4.4 实战中的频率调整策略
巡检频率不是一成不变的。我一般按这个节奏调整：
| 阶段 | 频率策略 | 说明 |
|---|---|---|
| 系统上线初期 | 高频（5分钟级） | 摸清系统脾气，建立基线 |
| 稳定运行期 | 中频（15~30分钟） | 基线已建立，减少资源消耗 |
| 大促/压测期间 | 超高频（1分钟级） | 临时提升频率，活动结束后恢复 |
| 系统退役前 | 低频（每天1次） | 只要不死就行，别浪费资源 |
说白了，巡检频率是个动态平衡的过程。你想想看，一个系统跑了半年都没出过事，你还每5分钟查一次，那不是浪费是什么？但反过来，一个新上线的系统，你一天才查一次，那叫不负责任。
嗯，关于巡检周期与策略，我就讲这么多。核心就一句话：定时巡检保底线，触发式巡检抓异常，两者配合才能把系统看牢。