云服务

概述 你公司用了某云厂商的服务，SLA 白纸黑字写着 99.95% 月度可用性。某天凌晨服务挂了 30 分钟，你跑去找云厂商索赔，拿回来的赔偿大概是这么算的：故障时间占月度总分钟数的比例，乘以你当月的服务费。假设你月付 1000 块，30 分钟除以 43200 分钟再乘 1000，赔你 0.7 元。 没看错，七毛钱。你线上炸了半小时，客服电话被打爆，用户退款申请堆了一屏，云厂商赔你七毛。 这不是段子，这是 2025 年某 CSDN 技术博客拆解云厂商 SLA 时用的真实计算逻辑。当然，实际云厂商的赔偿用的是阶梯制（后面会讲），但核心问题不变：SLA 的数字看着唬人，赔偿条款却藏着大量排除项和窄化定义，到了真出事的时候，赔的那点钱远远覆盖不了你的业务损失。 这篇文章不聊怎么"读懂"SLA——那种文章网上一搜一大把。我要聊的是：作为 SRE，你怎么设计自己服务的 SLA，怎么避免云厂商 SLA 的坑，怎么把一个合同条款变成可执行的工程约束。 SLA、SLO、SLI：别再混为一谈 很多团队把这三个词当同义词用。开会时"我们的 SLA 是 99.9%"，实际上说的是 SLO。这三个东西的区别不是文字游戏，搞混了会出真问题。 先上一张对比表，后面逐个展开： 维度 SLI（指标） SLO（目标） SLA（协议） 是什么 对服务质量的量化测量值 基于 SLI 设定的内部目标值 对外承诺的合同条款 面向谁 工程团队 工程团队 + 产品 客户 / 业务方 违约后果 无 冻结发布、投入稳定性修复 赔偿、合同违约 严格程度 客观事实，无严格/宽松之分 必须严于 SLA 比 SLO 宽松，留缓冲 典型例子 P99 延迟 = 120ms P99 延迟 < 200ms，成功率 > 99....