巡检策略的设计原则：SLA、可靠性与成本的博弈

做巡检策略，本质上是在做一道“减法题”。

你不可能监控所有东西，也不可能每秒钟都去查一次。资源有限，机器会挂，网络会抖，人也会累。所以策略设计的第一课，就是搞清楚三个核心约束：SLA 指标、可靠性权衡、成本控制。

我个人习惯，拿到需求先问三个问题：
1. 这个系统挂了，用户多久能忍？
2. 我为了发现故障，把系统搞挂了咋办？
3. 老板给的预算，够不够买我想要的监控能力？

这三个问题，正好对应了上面三个原则。咱们一个个拆开聊。

1. SLA 指标：别拍脑袋，拿数字说话

SLA 是巡检策略的“北极星”。没有 SLA，你的巡检频率就是瞎定。我曾经接手过一套系统，运维同学拍脑袋设了 5 分钟一轮的巡检，结果业务方说他们的 SLA 是 99.9%，折算下来全年宕机时间不能超过 8.76 小时。你想想看，5 分钟一轮的巡检，检测到故障再告警，人工响应再处理——根本来不及。

设计原则其实很简单：巡检周期必须小于 SLA 要求的故障恢复时间（MTTR）。

具体怎么算？这里给一个我常用的速算表：

不过我要提醒你：这个表只是起点，不是终点。SLA 还分为检测时间和修复时间。检测占用的时间越长，留给修复的窗口就越短。所以我的经验是：巡检周期不要超过 SLA 允许宕机时间的 1/10。举个例子，4个9的 SLA，允许宕机 52 分钟，那巡检周期最好控制在 5 分钟以内，给后续操作留出余量。

2. 可靠性权衡：别巡检把自己检挂了

这又是一个血泪教训。我曾经见过一个团队，为了追求“零漏报”，给核心数据库配了每秒一次的资源巡检脚本。结果脚本本身调用了大量系统视图，直接导致数据库负载飙升，把业务拖死了。说白了，巡检本身也是一种“负载”。

可靠性权衡，核心就是平衡两个指标：

• 检测覆盖率：你希望抓到多少比例的故障。
• 巡检入侵性：巡检操作对业务的影响有多大。

这两者，天然冲突。你想想看，如果想 100% 检测到磁盘坏道，你得每秒钟读一次全盘数据——这机器还能用吗？

我个人习惯的做法是分三档：

1. 轻量巡检（无侵入）：读取系统已有指标（CPU idle、内存剩余、TCP 连接数）。频率可以高，不影响业务。
2. 重量巡检（低侵入）：执行测试连接、写入测试文件、模拟用户请求。频率要低，最好错峰执行。
3. 破坏性巡检（高侵入）：重启服务、切换主备、触发故障转移。这些只能安排在变更窗口，且必须有人盯着。

举个例子，我对数据库做巡检时：

• 每 30 秒查一次 show global status（轻量）
• 每 5 分钟执行一次 select 1 测试连通性（中量）
• 每 24 小时做一次主备切换演练（重量，走变更流程）

3. 成本控制：用最少的钱，办最多的事

做技术的人很容易陷入“完美主义”，觉得不漏检、1 秒一次才叫专业。但你得算账。

成本控制的三个大头：

• 计算成本：巡检脚本消耗的 CPU、内存、网络流量。
• 存储成本：巡检结果要落库吧？历史数据要保留吧？一年下来磁盘开销不小。
• 人工成本：巡检结果谁看？告警谁处理？误报越多，人工浪费越严重。

我个人习惯，在确定巡检策略前，先画一个“成本-收益”矩阵：

你发现没有？越是昂贵的巡检，频率就要越低。这不是怕花钱，而是怕投入产出比失衡。我见过有人为了省成本，把所有巡检都拉到 10 分钟一次，结果故障发现延迟，损失比省下的监控费大几个数量级。也见过有人不计成本地堆巡检，结果监控系统比业务系统还吃资源。

真正的高手，会做“分层分级”：

• 核心链路：高频率 + 中低成本的巡检组合。
• 非核心链路：低频率 + 低成本巡检，甚至不做巡检，靠被动告警。
• 硬件层：遵循厂商建议的巡检参数，不要自作聪明去刷寿命。

嗯，这张图我放了很久。你看这三个节点，每个都在往外拉，你不去主动平衡，它们就会互相撕扯。我个人经验是：先定 SLA，再压成本，最后用可靠性来调节具体参数。先算清楚必须做到什么程度，然后找性价比最高的方案，最后用可靠性测试验证会不会出问题。

举个例子，我有一个核心支付系统，SLA 要求 4个9。我用轻量巡检每 30 秒看一次进程存活和端口监听，成本极低。每个 5 分钟用测试账号发起一笔小额支付请求，成本中等，但能真实验证业务链路。每 24 小时做一次主备切换，成本高，但能保证故障时你真的切的过去。你看，这就是按三角原则落地的实际策略。

小结一下我今天说的重点

• SLA 指标：别凭感觉设巡检频率。用公式算，MTTR 除以 10。
• 可靠性权衡：巡检不能成为故障本身。分轻中重三级，错峰执行。
• 成本控制：算清楚每笔巡检的账，核心资源多投，边缘资源少管。

记住，没有完美的巡检策略，只有当前成本约束下最靠谱的策略。后面我会带你们一步步把这个三角落到具体代码和脚本里去。