一、运维指标体系概述
为什么需要量化指标？
说实话，我见过太多运维团队了。大家每天忙得脚不沾地，老板问「你们干得怎么样？」——答不上来。
为什么？因为没有数据。
运维工作有个特点：不出事的时候，没人觉得你重要。一出事，所有人都在问「你们在干嘛？」。我个人习惯，从第一天带团队起，就坚持一件事——所有运维行为，必须可量化。
量化指标的价值，说白了就三点：
- 证明价值：你维护了1000台服务器，99.9%可用，这就是成绩
- 发现问题：平均响应时间从2秒涨到5秒，肯定哪里出问题了
- 指导改进：哪个环节最慢？瓶颈在哪？数据会告诉你
核心观点：没有指标，运维就是「黑盒」。有了指标，你才能从「救火队员」变成「系统架构师」。
MTTR 与 MTBF 核心概念
这两个概念，是运维指标体系的基石。我当年刚入行时，也搞混过。咱们一个一个说清楚。
MTBF（Mean Time Between Failures）—— 平均无故障时间
什么意思？就是系统「两次故障之间」能正常运行多久。
举个例子：你的服务器1月份坏了3次，分别在第5天、第15天、第25天。那么MTBF = (5 + 10 + 10) / 3 ≈ 8.3天。
MTBF 越高，说明系统越稳定。
MTTR（Mean Time To Repair）—— 平均修复时间
这个更好理解——从故障发生到恢复，花了多久。
还是刚才的例子：三次故障分别花了30分钟、45分钟、15分钟修复。那么MTTR = (30 + 45 + 15) / 3 = 30分钟。
MTTR 越低，说明你恢复能力越强。
我的经验：我在项目中遇到过一家电商公司，MTBF 很高（系统很稳），但 MTTR 也很高（每次修很久）。结果呢？一次大故障挂了4小时，损失几百万。所以别只看一个指标，两个要一起看。
用公式表示就是：
可用性 = MTBF / (MTBF + MTTR) × 100%你想想看，MTBF 是 100 小时，MTTR 是 1 小时，可用性就是 100/101 ≈ 99.01%。
避坑指南：我曾经见过一个团队，把「系统重启时间」算进 MTTR 里。结果呢？指标很好看，但用户感知很差。记住，MTTR 应该从用户感知到故障开始算，不是从你开始修算起。
SLA / SLO / SLI 定义与区别
这三个概念，很多人容易搞混。我刚开始也绕了很久。咱们用个比喻来理解。
你开了一家快递公司：
- SLI（Service Level Indicator）：你实际测量的数据。比如「今天100个包裹，98个在24小时内送达」。
- SLO（Service Level Objective）：你给自己定的目标。比如「99%的包裹要在24小时内送达」。
- SLA（Service Level Agreement）：你跟客户签的合同。比如「如果低于99%，赔你100块」。
说白了，SLI 是「实际值」，SLO 是「目标值」，SLA 是「承诺值」。
| 概念 | 定义 | 举例 | 特点 |
|---|---|---|---|
| SLI | 服务质量的实际度量指标 | 请求成功率 99.95% | 可测量、可监控 |
| SLO | 团队设定的目标值 | 请求成功率 ≥ 99.9% | 内部使用，可调整 |
| SLA | 对外承诺的服务等级 | 请求成功率 ≥ 99.5%，否则赔偿 | 有法律效力，有惩罚 |
关键点：SLO 一定要比 SLA 严格。比如你对外承诺 99.5%，内部目标至少要定 99.9%。为什么？留出余量。万一出点小问题，你还有缓冲空间。
嗯，这里要注意：SLI 选什么指标，直接决定了你的运维方向。我见过一个团队，SLI 只盯着「服务器CPU使用率」，结果呢？CPU 很低，但用户页面加载慢得要死。为什么？因为瓶颈在数据库，不在 CPU。
我个人建议：SLI 一定要从用户视角出发。比如「页面加载时间」「API响应时间」「订单成功率」。这些才是用户真正关心的。
知识体系总览
下面这张图，是我梳理的运维指标体系核心逻辑。你可以把它当作本章的「地图」。
这张图把本章的核心逻辑串起来了。从左到右：先搞清楚「为什么需要指标」，再掌握「MTBF/MTTR」这两个基础概念，最后理解「SLA/SLO/SLI」这套服务等级体系。每一步都是下一层的基础。
我的建议：刚开始搭建指标体系时，别贪多。先盯住3-5个核心指标，跑通流程。等团队习惯了，再逐步扩展。我见过太多团队，一上来就搞几十个指标，结果没人看得懂，最后全废了。
好了，这一章就到这里。量化指标这件事，说白了就是「用数据说话」。你有了数据，就有了话语权，就有了改进的方向。下一章，咱们聊聊具体怎么选指标、怎么搭看板。
公众号：蓝海资料掘金营，微信 deep3321