适用场景
运维考核最容易翻车的做法是只考「故障次数」。结果是没人敢报故障、小问题拖成大问题。合理做法是考服务目标（SLO）加过程质量（响应、闭环、文档、演练），并且指标要能被验证。
配置步骤（SLO 与错误预算实操）
# 1) SLO 定义示例
# 核心业务：可用性 99.9%/月（允许不可用 43.2 分钟）
# 延迟：P95 < 800ms
# 错误率：5xx < 0.1%
# 2) 计算（Prometheus 思路）
# SLI_可用 = 1 - (5xx 请求数 / 总请求数)
# 月度错误预算剩余 = 1 - 本月已用不可用时间 / 允许时间
# 3) 错误预算用尽的处理
# - 停止非必要变更
# - 集中做稳定性改进（容量、超时、重试、限流）
# - 改进完成并验证后恢复变更
# 4) 报表：月度 SLI 曲线 + 预算消耗 + 改进项清单关键参数与建议
- SLO 定义：可用性、延迟、错误率三类，按核心业务分级
- 错误预算：允许的不可用额度，用完就要停下来做稳定性改进
- 过程指标：响应及时率、一次解决率、闭环率、文档回写率
- 改进指标：重复故障下降、隐患整改完成率、演练完成率
- 数据来源：监控与工单自动统计，不靠人工填报
- 禁止项：不考「零故障」「工单数量」这类会被造假的指标
- 沟通机制：月度复盘讲数据和改进，不搞排名羞辱
容易踩的坑
- SLO 定得比业务实际要求高，团队被指标压死
- 只在故障时算，日常没监控，数据不可信
- 错误预算用尽后照常发布，指标形同虚设
- 把所有系统定同一目标，核心与内部系统混为一谈
- 没和业务确认可用性口径，用户侧体感和报表不一致
- SLI 采集漏掉关键接口，报表好看但用户仍投诉
验证与巡检
# 数据核对
# 1) 监控侧 5xx 数量 vs 网关日志统计
# 2) 可用性口径：按接口还是按业务事务
# 3) 预算消耗与变更记录的对应关系- 巡检：SLI 与日志一致、预算消耗有记录、改进项闭环、月度报表对业务可见
小结
考核体系检验：指标公示后，团队能否用同一套数据说清这个月哪里做得好、哪里需要改。能说清，体系才算立住。
> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。