核心要素解析：SLI、SLO、SLA 与错误预算的定义
-
SLI (Service Level Indiicator 服务级别指标）
衡量服务质量的“尺子”（如请求成功率，延迟），是所有度量的基础。
-
SLO (Service Level Objective 服务级别目标）
对SLI设定的具体目标值（如99%的请求成功率），是服务可靠性的核心约定。
-
SLA (Service Level Agreement 服务级别协议）
服务提供方与客户的正式协议，明确SLO承诺未达标时的补偿机制。
-
错误预算：基于SLO计算的容错额度
如SLO为99%可用性时，允许的年度不可用时间为8.76小时，用于平衡系统可靠性与创新速度的矛盾。
SRE 的底层逻辑：拒绝 “绝对可靠”，拥抱风险管控
首先要说明SRE的一个指导思想，谷歌认为试图建立一个百分百可靠的服务是愚蠢的，因为你要考虑在高可靠性（99.9%）到100%可靠时，可能会带来成本的大幅提升，且限制了新功能的开发速度和将产品交付给用户的速度。所以谷歌提倡面对风险，管理风险（度量服务的风险，设置风险容忍度-“错误预算”）。
如果不了解服务中各种行为的重要程度，且不度量这些行为的正确性的话，就无法正确运维这个系统，更不要说可靠的运维了。因此，不管是对外服务还是内部api，我们都需要制定面向用户的服务质量目标，并且努力达到这个目标，这是我们引入SLI、SLO、SLA的核心目的。
三者的递进关系是：SLI提供可量化的“度量基础”，SLO基于SLI设定“目标值”，SLA则将SLO转化为“对外承诺”。
从承诺到度量：SLI、SLO、SLA 的协同作用
SLA是一个服务级别协议，SLA的签署，可以让客户对系统稳定性有一个明确的预期，我们的服务可以给到你一个什么样的承诺，如果达不到，我们会进行相应的赔偿。在获取客户信任的同时，也对企业内部人员形成达成稳定性目标的约束。
为了让SLA的承诺可落地，我们需要设定一个明确的SLO（服务级别目标）。
SLO需要基于SLI设定（如“95%的请求延迟<=”），SLO的设定需要根据用户最关注的体验维度来选择（例如支付系统更关注正确性，视频服务更关注延迟）该目标的确立，还可以避免那些没有根据的抱怨（“服务太慢了”），如果没有数据指标支撑，用户经常会主观判断系统的稳定性，导致对服务可靠性的误判，带来不必要的麻烦。
为了设立一个正确的SLO，我们需要选择一个比较有意义的SLI，其选择原则包括：
- 以用户为中心（如关注用户感知的延迟，而非服务器内部延迟）；\
- 可度量，可操作（如“吞吐量”需明确单位：每秒请求数）；\
- 数量精简（3-5个，避免分散注意力）
常见的几类服务的SLI可参考：
- 用户可见系统服务（前端服务器）：
- 可用性（是否能正常处理请求）
- 延迟（每个请求花费的时间）
- 吞吐量（多少请求可以被处理）
- 存储系统：
- 延迟（读写数据需要多少时间）
- 可用性（是否可以随时访问数据）
- 持久性（数据是否一段时间内还能被读取）
- 大数据系统：
- 吞吐量（处理了多少数据）
- 端到端延迟（数据从输入到产出需要多少时间）
- 所有系统：
- 正确性（是否返回了正确的回复）
研发与 SRE 的目标协同：错误预算如何化解矛盾？
面对部门协作时，技术部通常由产品研发小组和SRE（运维）小组构成，而由于各小组工作内容不同，目标也存在天然矛盾：
产品研发小组绩效常与研发速度挂钩，这会激励员工快速迭代新功能并迅速发布；
SRE绩效取决于该服务的可靠性，这意味着SRE更关注变更风险，拒绝高频率发布。
为解决这一矛盾，需要基于SLO定义一个双方认可的客观指标- 错误预算，来平衡双方需求，激励产品研发和SRE一起找出创新性和可靠性之间的平衡点。
实操指南：错误预算如何指导发布与问题修复？
- 产品管理层基于用户需求定义SLO（如 "季度可用性≥99.9%"），并设定时间窗口（核心服务常用 30 天滚动窗口，平衡短期波动与长期趋势）；
- 实际服务质量由中立监控系统测算（基于 SLI 实时统计）；
- 错误预算 = SLO 允许的最大故障额度 - 实际故障消耗（例如：99.9% 可用性对应 30 天内允许 43.2 分钟不可用，若实际故障 20 分钟，则剩余预算 23.2 分钟）；
- 错误预算消耗场景包括：可用性不达标、延迟超标、错误率过高等所有 SLO 约定的 SLI；
- 只要剩余错误预算充足（实际指标达标），即可正常发布新功能；
- 若错误预算耗尽（指标未达 SLO），需暂停非紧急发布，优先修复问题（如优化代码、扩容资源），直至后续稳定运行使滚动窗口内的预算 "回血"。
