线上巡检报告不是写流水账：一份能救命的巡检长什么样
一、元认知：巡检到底在检什么 #
很多团队把巡检做成”看一遍监控大盘”——打开 Grafana 截几张图，写上”一切正常”，发到群里。这不是巡检，这是签到。
巡检要解决的根本矛盾是：生产系统永远在缓慢走向故障，而告警只在越过阈值的那一刻才响。告警是被动的”事件触发”，巡检是主动的”状态采样”。两者不可互相替代。
- 告警回答：”出事了吗？”——单点阈值、瞬时判断、事后响应
- 巡检回答：”正在出事吗？快要出事了吗？”——趋势判断、关联判断、事前干预
理解这一层，就明白为什么巡检报告不能只有”当前值”，必须有同比、环比、容量趋势三看。一个 CPU 60% 的当前值毫无信息量——它可能是凌晨低谷（正常），也可能是峰值前的爬坡（危险）。脱离趋势的指标采集等于没采。
巡检的第二个根本属性是闭环。一次巡检不是终点，而是上一次巡检待办的复核节点 + 本次新风险的登记节点。没有闭环跟踪的巡检，等于每天都在重新发现同一个问题却永远不修。大厂把巡检报告视为”事件前态基线”——故障复盘时回头查巡检报告，看故障发生前系统是否已有征兆、巡检是否抓到了征兆、是否登记了风险。巡检质量直接关乎复盘结论。
二、搭积木：一份完整巡检报告的结构 #
巡检报告的本质是一个结构化文档，由元信息 + 巡检维度 + 结论跟进三段式构成。每一段都有明确的信息密度要求，缺一不可。
2.1 元信息（Header） #
元信息不是”装饰”，它是报告可追溯、可检索、可比对的前提。一份没有元信息的巡检记录，三个月后翻出来谁也看不懂上下文。
| 字段 | 说明 |
|---|---|
| 巡检ID/批次 | 唯一标识，便于复盘时引用 |
| 巡检时间窗口 | 起止时间，精确到分钟 |
| 巡检人 / 复核人 | 主备双岗，主巡写报告，复核签字 |
| 巡检范围 | 服务列表、集群、机房、可用区 |
| 巡检类型 | 日常 / 节前 / 大促前 / 变更后 / 故障后 |
| 整体状态 | 🟢正常 / 🟡警告 / 🔴异常 |
主备双岗不是形式主义。主巡的视角会盲，复核人盯着不同维度，能把”主巡觉得没事但其实有事”的盲点捞回来。大厂节前巡检甚至会安排三人交叉复核。
2.2 核心巡检维度（5+1） #
巡检维度是从”系统从哪儿出问题”反推出来的。一个在线服务出问题，无非五个方向：业务没流量/没转化、资源不够用、中间件挂了、整体可用性掉、依赖方挂了。再叠加一个横切的合规安全维度。
① 业务指标（北极星） #
业务指标是巡检的第一站，不是系统指标。理由很朴素：系统全绿但业务掉量，一定有地方坏了，只是监控没覆盖到。业务指标是最敏感的”系统健康度探针”。
- 流量：QPS/TPS、同比（上周同时段）环比（昨日同时段）、分时段曲线异常波动
- 成功率：核心接口成功率（一般门槛 >99.9%）、错误码分布 TOP5
- 业务漏斗：下单→支付→履约各环节转化率异动
- 资损监控：对账差异、幂等失败、重复扣款
阿里实践：每个一级业务有 12-15 个”业务大盘”核心指标，设 ±10% 波动即告警。这套指标体系被称为”业务健康度模型”，巡检时必须挨个核对。
为什么是 ±10% 而不是固定阈值：业务有周期性，工作日和周末流量差几个量级，固定阈值要么天天误报要么漏报。相对波动比绝对值更稳。
② 系统资源（容量水位） #
资源巡检的核心问题是”还有多少余量”，而不是”现在多少占用”。一个 80% 的 CPU，余量还有 20%、还能扛住下一波高峰，那就正常；余量只剩 5%、马上大促，那就告急。
- CPU/内存/磁盘/网络：峰值、均值、是否触达容量水位线
- 容量余量：相对峰值预估（余量 <30% 标黄，<15% 标红）
- 资源瓶颈 TOP5：最紧张的资源排序，便于决策扩容优先级
- 存储：日志、DB、缓存容量，增长趋势线是否线性外推将触顶
腾讯经验：水位监控区分”流量水位”和”资源水位”。流量水位决定限流阈值怎么调，资源水位决定扩容决策怎么定。两个水位不能混看，否则要么过早限流伤业务，要么该扩容没扩容。
关于水位线设置：很多团队直接拿 70%/80%/90% 当黄红线，这是错的。水位线应该按”剩余容量能扛多久“算，不是按”占用百分比”。一个写入速度 100GB/天的日志盘，剩余 100GB 和剩余 1TB 对应的紧迫度完全不同，光看”已用百分比”会误判。
③ 应用健康（中间件） #
中间件巡检是最容易写出深度的部分，因为每个中间件都有自己的”病征对照表”。
- 数据库：慢查询 TOP、连接池占用、主从延迟、死锁记录
- 缓存：命中率、BigKey/HotKey、内存碎片率、淘汰频率
- MQ：堆积量、消费延迟、消费 TPS、死信队列长度
- 网关/LB：5xx 比例、超时率、长尾延迟 P99/P999、限流触发次数
字节实践：每个中间件有”健康分”（0-100），<60 自动告警。健康分不是单一指标，是按权重综合计算。例如 Redis 健康分 = 命中率×0.3 + 内存余量×0.2 + BigKey数量×0.2 + 主从延迟×0.2 + 慢日志×0.1。
慢查询 TOP 不是看慢不慢，是看变化：一条稳定存在的慢查询不可怕（早就该优化但没出事），新出现的慢查询最可怕，往往对应索引失效、数据量拐点、或执行计划突变。巡检时必须标”新增慢查询”。
主从延迟的真相：主从延迟 >1s 就要重视，但更要看延迟是否在收敛。延迟在涨是恶化，延迟在掉在收敛是自愈。盲目告警会制造噪音。
④ 可用性（SLA / SLO） #
可用性巡检的核心是**”错误预算消耗进度”**，不是本月挂了几次。
- 服务可用率：分钟级可用率、月度 SLA 余额
- 故障统计：当班期间 P0/P1/P2 故障数
- 告警数量：按服务 / 级别分类，重复告警和无效告警占比（占比高说明告警规则该治理了）
- 预案演练：是否执行了混沌工程 / 容灾切换
Google SRE 经典框架：错误预算 = 100% − SLA 目标。若 SLA 是 99.9%，月度错误预算是 0.1%×43200 分钟 = 43.2 分钟。巡检时看”本月已消耗多少错误预算”，消耗过半就冻结变更，消耗 80% 就只允许修 bug 不允许新功能。
错误预算思维把”可用性”从”事后统计”变成”事前约束”。巡检报告的核心问题变成：“这个月我们还剩多少犯错额度”，比”本月可用率 99.95%”信息量大得多。
告警治理是巡检的衍生动作。巡检时如果发现某服务当月告警 200 条、其中 190 条是重复无效，说明告警规则在噪音化，必须推动收敛。否则真告警会被淹没——狼来了的故事在生产系统里每天都在重演。
⑤ 变更与依赖 #
70% 的故障源于变更。所以变更台账是巡检报告的必填项，不是可选项。
- 当天变更：发布、配置、灰度、回滚记录，关联到对应故障标注
- 上下游异常：强依赖服务的健康度评分
- 外部依赖：第三方 API 可用率、DNS / CDN 健康度
- 窗口约束：是否在低峰期，是否在变更冻结窗口
美团经验：变更与故障强相关，变更台账必须可追溯到具体 commit、变更人、审批人。巡检时要标注”当天有变更的服务”和”当天有故障的服务”之间是否重叠——重叠即是首要嫌疑。
为什么巡检时要看变更而不是等告警：变更产生的故障有潜伏期。一个配置改错了，可能 10 分钟后才暴露（缓存逐步失效、连接池逐步打满）。巡检时主动关联变更与异常，能在”告警响之前”介入。
外部依赖的诚实：很多团队巡检时只看自家系统，不查上游依赖。但对外承诺 SLA 时，上游挂了你一样违约。外部依赖可用率必须纳入巡检，第三方 API 抖动要标红。
⑥ +1：安全合规 #
大厂巡检报告标配这一栏，小厂常忽略。忽略的代价是某天证书过期整站挂掉，或某次越权访问引发数据泄露。
- 异常登录：非工作时间、非常用 IP、提权操作
- 越权访问：敏感接口未授权调用记录
- 敏感数据扫描命中：日志里是否意外写入密钥、手机号、身份证
- 证书到期：7 天 / 30 天 / 60 天多级告警
- 配置漂移：生产配置 vs 基线配置差异检测
证书到期是最无聊但最致命的巡检项。Let’s Encrypt 90 天证书，巡检时不查就一定有人会忘。多级告警的逻辑是：60 天提示续期，30 天必须执行，7 天升级为故障。证书过期的故障案例年年都有，从未绝迹。
2.3 结论与跟进（闭环段） #
报告最后一段不是写感想，是写待办和责任人。
| 项 | 内容 |
|---|---|
| 风险清单 | 已识别风险分级（高 / 中 / 低） |
| 待办事项 | 责任人 + 截止时间 + 优先级 |
| 历史遗留 | 跟踪上次巡检未闭环的待办 |
| 升级建议 | 是否需升级至周会 / 月报 |
待办必须进工单系统，不能只躺在巡检报告里。报告归档可检索，工单系统跟踪执行。下次巡检第一步是查上次待办的闭环状态——没闭环的标红，连续两次未闭环的升级到主管。
三、案例即原理：从一份反面报告学正面逻辑 #
下面这份反面报告，节选自某团队节前巡检真实记录（已脱敏），用来演示每一处缺陷对应的原则缺失。
1 | |
逐条拆解：
缺陷 1：只有当前值，没有趋势——“CPU 60%” 是凌晨 3 点的值还是晚高峰的值？同比如何？没说。读者无法判断这是高峰低谷还是爬坡中。整改：必须加时间窗口、同比、环比。
缺陷 2：”无慢查询”是假的——任何有一定流量的库都有慢查询，只是阈值设了没采集到。真要写”无慢查询”必须附阈值标准。整改：写”慢查询阈值 >500ms，当班周期内 0 条”，并对比昨日是否新增。
缺陷 3”告警 15 条都已处理”是闭环假象——“已 ack”不等于”已处理”。ack 了但根因没修，下次还会响。整改：必须分类”已闭环 / 待修复 / 无法修复”。无法修复的要标原因（如第三方问题）。
缺陷 4：”当天无故障”但没提变更——节前巡检最关键是看变更冻结是否执行。没提变更记录，等于没巡检变更维度。整改：必须有”变更冻结窗口”和”窗口内是否有违规变更”两栏。
缺陷 5：结论”继续观察”等于没结论——巡检结论必须是具体待办：哪个容量吃紧该扩容、哪个告警规则该优化、哪个慢查询该建索引。”继续观察”是逃避决策的话术。整改：每条结论必须落到责任人和截止时间。
缺陷 6：整份报告无外部依赖巡检——如果上游支付通道抖动了 30 分钟，这份报告看不出。整改：外部依赖可用率必填，无异常也要写”已核查，正常”。
这份反面报告的共同病根是：把巡检当作”打卡动作”而非”风险发现动作”。每一条都在描述”我看了什么”，没有一条在回答”我判断了什么”。规范的巡检报告每一项指标后面都要跟一句判断：正常 / 异常 / 趋势恶化 / 待跟进。
四、缺陷与批判：巡检机制的天然局限 #
巡检制度不是万能的，它有几个必须承认的天然缺陷，理解这些缺陷才知道巡检的边界在哪、什么时候不能依赖巡检。
4.1 采样间隔存在盲区 #
巡检是离散采样，告警是连续监测。两次巡检之间发生的瞬时抖动、自愈型故障、雪崩-恢复事件，巡检发现不了。把巡检当主要发现机制是错位的——巡检是发现”慢性病”，不是发现”急性心梗”。急性事件必须靠告警 + 自动化预案。
4.2 巡检人疲劳导致漏判 #
人巡的极限是 30-40 个指标，超过就疲劳。大厂巡检动辄几百个指标，靠人挨个看不现实。于是演化出两种相反的失败模式：
- 巡检模板太长，人巡数据没看就打勾——形式巡检
- 巡检模板太短，关键维度被裁掉——内容巡检不全
解法是自动化巡检平台：机器采数据、机器比阈值、机器出报告草稿，人只做”判断题”（标红指标需不需要升级）。大厂普遍有自研巡检平台，开源方案可以用 Prometheus + Alertmanager + 自定义报表生成。但自动化不等于零人工——人需要确认平台的判断、补充上下文、给出处置建议。
4.3 巡检门槛与团队成熟度强相关 #
巡检报告的深度取决于团队对系统的理解深度。新人巡检只能看”数值在不在范围内”，老兵巡检能看出”这个数值的拐点对应上周那个变更”。同一份报告，深度天差地别。
这意味着巡检不能完全交给值班新人。大厂惯例是：日常巡检可由 SRE 新人执行，节前 / 大促前巡检必须由资深 SRE + 业务 owner 联合执行，故障后巡检必须有写过那个模块的同学参与。
4.4 巡检报告本身会变成噪音 #
当巡检报告日复一日都是”正常”，团队会逐渐不再看它。这是正常的人性反应——人对不变的信息会脱敏。严重的副作用是：某天报告突然出现异常项，但已经没人看了。
对抗这种脱敏的工程手段是分级推送：
- 整体 🟢 正常：发到值班群，不 @ 任何人
- 🟡 警告：@ 值班人本人
- 🔴 异常：@ 值班人 + 主管 + oncall 二线
并且报告里”正常”项要精简（一行带过），”异常 / 趋势恶化”项要展开。让阅读者的注意力天然聚焦到有变化的字段。
4.5 巡检闭环的官僚化风险 #
闭环管理是刚需，但执行过头会变成官僚主义——每次巡检填一堆工单、催一堆进度、抄送一堆人，最后大家都在为流程而流程，没人真正在改进系统。
判断闭环是否健康的标志：过去 30 天巡检待办的”实际修复数 / 总待办数”比值。低于 50% 说明工单系统沦为登记册，没有执行；高于 90% 说明要么待办太少（巡检太浅），要么团队被工单压垮（要么扩人，要么删无效工单）。健康区间是 60-80%。
五、总结巡检这件事本身 #
回到最根本的问题：巡检是什么？
巡检不是文档，是把生产系统当前状态与”应有状态”做差分比对、并把差分转化为可执行待办的过程。报告是这个过程的副产物，不是目的。
好的巡检有三个不可妥协的属性：
- 可判断——每个指标都带判断结论，不是数据罗列
- 可追溯——所有判断可回溯到指标、巡检人、时间窗口，故障复盘时能定位”事前是否已知”
- 可闭环——所有风险都进工单系统，下次巡检首查闭环状态
差的巡检有一个共同特征：只在描述”我看了”，从未回答”我判断了”。前者是签到，后者才是巡检。
最后，巡检制度的真正价值不在单次报告，而在积累起来的趋势档案。一份月度巡检报告只能反映当下，12 份月度报告叠加能看出系统的退化曲线——容量是怎么吃紧的、慢查询是怎么多起来的、告警噪音是怎么涨上来的。这种** longitudinal（纵向）视角**才是巡检制度最珍贵的产出，也是为什么巡检报告必须标准化模板、长期归档、可检索比对。
巡检不是动作，是工程纪律。纪律的价值要在三年后才完全显现——那些坚持巡检三年的团队，故障率一定显著下降；那些把巡检做成签到的团队，三年后还在为同一类故障复盘。