可靠性不是感觉：SLI、SLO、SLA三层拆解

74%的企业说不清自己的服务承诺到底意味着什么——这是Xurrent 2023年报告里的数字。不是技术做不到，是概念本身被混着用。SLI、SLO、SLA三个词在会议室里来回串，最后变成"我们尽量保证稳定"这种模糊表态。等真出故障的时候，没人说得清问题是从哪一层开始崩的。

这三件事其实是层层递进的关系。SLI回答"系统现在怎么样"，SLO回答"我们希望它怎么样"，SLA回答"我们向客户承诺了什么"。搞混任何一层，可靠性就从可测量的指标变成靠感觉猜的状态。

SLI（服务等级指标）是唯一跟真实系统挂钩的那层。Google的SRE手册把它定义为"有效事件中正常事件的比例"，0%是全挂，100%是完美。实际工程里最常用的四个指标直接对应用户感受：可用性（成功请求占比）、延迟（请求耗时）、错误率（失败请求占比）、吞吐量（每秒处理量）。这里有个细节：延迟必须看分位数，不能看平均数。RadView的压测案例很典型——2000并发下平均响应280毫秒，但p99是3.4秒。平均值把长尾吃掉了，业务关键路径得用p95、p99甚至p99.9。

SLO（服务等级目标）是团队给自己定的内部靶子。它包含三个要素：具体数值（如99.95%可用性）、时间窗口（如过去30天）、错误预算（允许多少次不达标）。SLO的关键在于"内部"——这是团队在对外承诺之前，先跟自己较真的那条线。定得太松，SLA就成了空话；定得太紧，团队被报警淹没。

SLA（服务等级协议）是最终面向客户的合同。它把SLO翻译成赔偿条款和违约后果。大多数SLA只覆盖可用性，但聪明的团队会把延迟和错误率也写进去——因为用户真正生气的时候，往往不是服务挂了，而是卡了半分钟还没反应。

三层都定好了，还有一个问题：这些数字可信吗？答案是压测。没有负载测试验证过的SLO，只是愿望清单。压测能告诉你，在真实流量形状下，p99什么时候开始失控，错误预算什么时候真的会被烧完。SLI、SLO、SLA三层体系，最后靠压测来落地——否则可靠性工程就停在纸面上。