SRE 实战手册（二）｜没有故障，系统就一定是稳定的吗？

SRE 实战手册二没有故障系统就一定是稳定的吗对应课程「02系统可用性没有故障系统就一定是稳定的吗」本篇聊一个反直觉的命题可用性Availability≠ 稳定性Reliability以及为什么没故障往往是假象。一、从可用性这个数字说起做运维的人对可用性不陌生最常见的公式是可用性 正常运行时间 / (正常运行时间 故障时间)也就是大家熟悉的几个 9等级年停机时间99%~3.65 天99.9%~8.76 小时99.95%~4.38 小时99.99%~52.6 分钟但课程里赵成老师点出了一个关键区别可用性是有没有响应稳定性是响应得符不符合预期。举一个我们 Demo 里的真实例子。假设悦购电商的结账接口POST /api/checkout场景 A接口 1% 的请求返回 500真故障→ 可用性 99%但用户明显感知到下单总失败。场景 B接口 100% 返回 200但平均延迟从 80ms 涨到 3s性能劣化没报错→ 可用性 100%可用户早跑光了。场景 B 没有一次故障但系统稳定吗显然不。这就是为什么 SRE 不盯着有没有宕机而是盯着 SLI后面第 03 讲会细讲。二、没有故障为什么常常是假象课程里总结了三个最常见的认知盲区1. 故障被平均吃掉了平均延迟 200ms 看着健康背后可能是 99% 请求 50ms、1% 请求 20s。被平均掩盖的那 1%就是稳定性地雷。SRE 看的是分位数p99、p999而不是平均值。2. 故障是局部的但影响是全局的一个下游依赖比如支付网关变慢不会让主服务宕机但会让每一个经过它的请求变慢。监控大盘上核心服务存活绿灯长亮业务侧却已经哀鸿遍野。只看服务是否 up等于蒙着眼睛开车。3. 故障是间歇性的但根因是持续性的很多团队用今天有没有 P 级故障来评判稳定性结果就是平时疯狂累积技术债然后周期性地来一次大故障。SRE 的思路相反用错误预算把小问题的累积显性化——只要错误率在烧预算哪怕没触发故障也要有人管。三、用实验环境验证延迟也算不稳定我们的 Demo 支持动态注入延迟不用改代码、不用重启# 在任一业务节点上注入 800ms 额外延迟bash/opt/sre-lab/fault.sh latency800此时POST /api/checkout仍然 100% 返回 200可用性 100%但我们定义的 SLI比如 p99 延迟会被立刻拉高。Prometheus 里能看到sre_http_request_duration_seconds_bucket{endpointcheckout,le2.0}直方图桶里le1.0的累计计数增长变慢、leInf增长变快——这就是没故障但劣化在指标上的样子。这正好印证了课程的观点稳定不是不报错而是关键体验指标持续落在预期区间内。四、从可用性到可靠性SRE 的度量转向把这一讲收个口维度可用性传统可靠性SRE关注点服务是否响应响应是否符合预期主指标宕机时长SLI延迟/错误/饱和度…盲区忽略慢和错但没挂显式覆盖体验劣化度量几个 9SLO 错误预算所以回到标题的问题——没有故障系统未必稳定。真正该问的是我们对用户承诺的体验有没有被持续满足而要把这句话落地就需要下一讲的工具SLI/SLO。五、小结与思考题可用性 ≠ 稳定性“没报错不等于体验好”。平均指标会掩盖长尾看分位数p99/p999。局部劣化、间歇故障靠有没有宕机是发现不了的。思考题你们现在的监控大盘上绿灯全亮的时候用户真的满意吗有没有一种全绿但业务在掉的场景是你们当前指标体系覆盖不到的下一篇进入 SRE 最硬核也最实用的切入点选 SLI、定 SLO。