4、系统稳定性度量：可用性(SLA/SLO/SLI)、错误预算、告警响应时间、故障根因分析

聊到系统稳定性，很多团队第一反应就是「看 SLA」。但说实话，我见过不少团队把 SLA 当成一个挂在墙上的数字，出了故障才想起来看一眼。这其实挺可惜的。

稳定性度量不是事后算账，而是帮我们提前发现问题的。今天我就把这块的核心逻辑拆开揉碎，跟你聊聊。

4.1 可用性：SLA、SLO、SLI 到底啥关系？

这三个词经常被混着用，但它们的角色完全不同。我习惯这么理解：

• SLI（服务等级指标）：你实际测出来的数据。比如接口响应时间、错误率。
• SLO（服务等级目标）：你给自己定的目标。比如「99.9% 的请求要在 200ms 内完成」。
• SLA（服务等级协议）：你跟客户签的合同。达不到要赔钱的。

说白了，SLI 是「你做到了什么」，SLO 是「你想做到什么」，SLA 是「你承诺了什么」。我见过最典型的坑是：团队把 SLO 定得比 SLA 还高，结果天天报警，自己把自己逼疯了。

4.2 错误预算：给故障留点空间

你想想看，一个系统不可能 100% 可用。如果你要求团队「零故障」，那结果往往是没人敢上线新功能。

错误预算就是解决这个矛盾的。它的逻辑很简单：

• 如果 SLO 是 99.9%，那一年允许的不可用时间是 8.76 小时。
• 这 8.76 小时就是你的「错误预算」。
• 预算没用完，说明你可以大胆发布新功能。
• 预算快花光了，那就暂停发布，先修稳定性。

我在项目中遇到过这样的情况：一个团队为了追求 100% 可用性，把所有变更都卡死了。结果半年下来，业务需求堆积如山，系统反而因为不更新变得更脆弱。后来引入错误预算，大家反而更理性了。

4.3 告警响应时间：别让告警变成噪音

告警响应时间，说白了就是「从告警发出到有人处理」的时间。但这里有个很容易被忽略的问题：告警太多了，反而没人响应。

我见过最夸张的一个系统，一天告警 2000 多条。值班同学直接静音了——反正也看不完。这其实是个管理问题，不是技术问题。

关于告警响应，我有几个经验：

• 分级响应：P0 告警 5 分钟内必须有人处理，P1 可以 15 分钟，P2 走工单。
• 告警去重：同一个故障不要重复报警。我见过一个磁盘满了的告警，因为每 5 分钟检查一次，一晚上发了 200 条。
• 告警要有「可操作性」：告警信息里直接告诉值班人员「该看哪个日志」「该执行什么命令」。我曾经收到过一条告警，就四个字「系统异常」——这跟没告警有啥区别？

4.4 故障根因分析：别只修表面

故障发生了，修好了，然后呢？很多团队就到此为止了。但真正的高手会问一句：「为什么会这样？」

根因分析（RCA）不是找一个人背锅，而是找到系统层面的漏洞。我常用的方法是「5 Why 分析法」：

• 问 5 次「为什么」，直到找到根本原因。
• 比如：数据库挂了 → 为什么？磁盘满了 → 为什么？日志没清理 → 为什么？定时任务没执行 → 为什么？脚本权限配置错误。
• 你看，最后的问题其实是「配置管理不规范」。

根因分析有个关键点：不要只修「这一次」的问题，要修「这一类」的问题。比如某个接口超时，你加了个超时重试，这只是治标。真正要做的，是看看为什么这个接口会慢，是不是依赖的服务不稳定，或者代码里有性能瓶颈。

知识体系总览

下面这张图是我自己梳理的稳定性度量核心逻辑，你可以对照着看：

这张图把四个核心维度串起来了。你仔细看会发现，它们不是孤立的——错误预算依赖 SLO 的定义，告警响应时间影响故障恢复速度，根因分析又反过来优化 SLO。这是一个闭环。