适用场景

运维考核最容易翻车的做法是只考「故障次数」。结果是没人敢报故障、小问题拖成大问题。合理做法是考服务目标（SLO）加过程质量（响应、闭环、文档、演练），并且指标要能被验证。

配置步骤（复盘与改进闭环）

# 复盘模板（30 分钟内写完）
# 1) 现象与影响：用户侧表现、影响时长、影响范围
# 2) 时间线：发现 → 定位 → 处置 → 恢复
# 3) 根因：直接原因 + 根本原因（用 5 Why）
# 4) 处置评价：哪些动作有效、哪些浪费时间
# 5) 改进项：责任人 + 完成时间 + 验收方式

# 复盘纪律
#   - 对事不对人，先讲事实再讲判断
#   - 改进项不超过 5 条，且必须可验证
#   - 同类故障二次发生，要追查上次改进是否落地

关键参数与建议

  • SLO 定义：可用性、延迟、错误率三类，按核心业务分级
  • 错误预算：允许的不可用额度，用完就要停下来做稳定性改进
  • 过程指标：响应及时率、一次解决率、闭环率、文档回写率
  • 改进指标：重复故障下降、隐患整改完成率、演练完成率
  • 数据来源：监控与工单自动统计，不靠人工填报
  • 禁止项：不考「零故障」「工单数量」这类会被造假的指标
  • 沟通机制：月度复盘讲数据和改进，不搞排名羞辱

容易踩的坑

  • 复盘开成追责会，后面没人说真话
  • 改进项写「加强监控」这类无法验收的话
  • 复盘完没人跟踪，下次同样故障重复
  • 只复盘大故障，小故障的隐患被忽略
  • 时间线凭记忆写，和日志对不上
  • 改进项太多，最后一件事都没做完

验证与巡检

# 改进项跟踪表
# 编号 | 改进内容 | 责任人 | 完成时间 | 验收结果

# 重复故障统计：同根因故障次数（季度）
  • 巡检：复盘 24 小时内完成、改进项闭环率、重复故障下降趋势

小结

考核体系检验：指标公示后，团队能否用同一套数据说清这个月哪里做得好、哪里需要改。能说清，体系才算立住。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。