第二章：巡检制度与规范
说实话，我刚入行那会儿，巡检就是个「想起来就做」的活。直到有一次，一条专线半夜断了，我们翻遍日志才发现——上次巡检记录是三个月前的。嗯，从那以后，我彻底明白了：没有制度，巡检就是走过场。
这一章，咱们聊聊怎么把巡检这件事「制度化」。说白了，就是定好规矩、分好工、写好报告。我踩过的坑，你就不用再踩了。
2.1 巡检周期定义
巡检周期怎么定？不是拍脑袋决定的。我个人习惯，先看业务等级，再看设备状态。
| 业务等级 | 巡检频率 | 适用场景 |
|---|---|---|
| 核心级 | 每日一次 | 金融、政务、数据中心互联 |
| 重要级 | 每周一次 | 企业总部、大型分支机构 |
| 普通级 | 每月一次 | 一般办公、非关键业务 |
| 备用链路 | 每季度一次 | 冷备线路、应急通道 |
你想想看，核心业务一天不巡检，出问题可能就是几百万的损失。我遇到过一家银行，他们的专线巡检是「早中晚三次」，雷打不动。为什么？因为交易数据丢一秒都不行。
我的小技巧： 新链路刚上线的前两周，建议加密巡检频率。我一般会按「每日一次」跑两周，等稳定了再降频。这叫「蜜月期巡检」，能发现很多隐藏问题。
2.2 巡检人员职责
职责不清，是巡检最大的坑。我曾经见过一个团队，三个人都觉得「对方会去巡检」，结果谁都没去。所以，职责必须白纸黑字写清楚。
2.2.1 初级运维工程师
- 执行日常巡检任务，按 checklist 逐项检查
- 记录设备运行状态（CPU、内存、端口流量）
- 发现异常立即上报，不擅自处理
- 填写巡检日志，确保数据准确
2.2.2 高级运维工程师
- 审核初级工程师的巡检报告
- 处理巡检中发现的异常问题
- 制定巡检优化方案（比如调整阈值）
- 每月汇总巡检数据，做趋势分析
2.2.3 网络运维主管
- 制定巡检制度和规范
- 抽查巡检执行质量
- 审批巡检报告中的变更请求
- 组织月度巡检复盘会议
注意： 我曾经见过一个团队，让初级工程师直接处理故障。结果他把一个端口 shutdown 了，导致整个分支网络瘫痪。记住：巡检是「发现」问题，不是「解决」问题。处理权限必须分级。
2.3 巡检报告模板
报告怎么写？我见过最离谱的，就写一行字「一切正常」。这跟没写有什么区别？一份合格的巡检报告，至少要包含以下内容。
2.3.1 报告结构
【专线巡检报告】
━━━━━━━━━━━━━━━━━━━━━━
1. 基本信息
- 巡检日期：2024-01-15
- 巡检人员：张三
- 巡检范围：核心专线 A、B、C
- 巡检类型：日常巡检
2. 设备状态
- 设备名称：PE-01
- CPU 使用率：23%（正常）
- 内存使用率：45%（正常）
- 端口状态：全部 UP
- 光模块功率：-2.3dBm（正常范围 -1 ~ -8dBm）
3. 链路质量
- 延迟：2.1ms（基线 2.0ms）
- 丢包率：0.01%（阈值 0.1%）
- 抖动：0.3ms（阈值 1ms）
4. 异常记录
- 无异常
5. 备注
- 设备 PE-02 风扇转速偏高，已记录，计划下周更换
━━━━━━━━━━━━━━━━━━━━━━2.3.2 关键指标基线
为什么要有基线？说白了，没有基线你就不知道「异常」长什么样。我习惯给每条专线建一个「健康档案」。
| 指标 | 正常范围 | 警告阈值 | 严重阈值 |
|---|---|---|---|
| 延迟 | 基线 ± 20% | 基线 + 50% | 基线 + 100% |
| 丢包率 | < 0.1% | 0.1% - 0.5% | > 0.5% |
| CPU 使用率 | < 60% | 60% - 80% | > 80% |
| 光模块功率 | -1 ~ -8dBm | -8 ~ -12dBm | < -12dBm |
核心观点： 巡检报告不是「写给别人看的」，是「给自己留证据的」。哪天出了故障，翻出巡检报告，你能清楚地知道「故障前设备是什么状态」。这就是你排查问题的底气。
2.4 巡检制度的核心逻辑
说了这么多，其实就三件事：定周期、分职责、写报告。我画了一张图，帮你理清思路。
这张图你看懂了吗？三个环节缺一不可。周期定得再好，没人执行就是空话；执行得再勤，不写报告就是白干。
避坑指南： 我曾经见过一个团队，报告写得特别漂亮，但全是「一切正常」。后来出故障了才发现，设备早就报警了，只是没人看报告。所以，我建议你加一条规则：巡检报告必须包含至少一条「异常记录」或「改进建议」。没有异常？那就写一条「设备运行稳定，建议保持」。至少证明你真的看了。
好了，这一章的内容就这些。制度这东西，一开始会觉得麻烦，但坚持三个月，你会发现——出故障的概率至少降一半。嗯，我试过。
公众号:蓝海资料掘金营，微信deep3321