服务等级目标把可靠性变成可管理边界

“系统要稳定”无法直接指导设计和运营。团队需要说明用户在什么交互上获得何种服务、怎样测量成功，以及多长时间内允许多少失败。服务等级指标提供测量，服务等级目标规定期望范围，错误预算把目标内允许的不可靠量转化为发布和改进的决策空间。

SLI 从用户可感知结果开始

服务等级指标（SLI）是对服务行为的定量测量。典型指标不是服务器是否存活，而是请求是否成功、响应是否在目标时间内完成、数据是否足够新、任务是否正确处理。选择指标时要先定义用户动作和成功条件。

请求成功率的分母和分子都需要边界。主动取消是否计入失败，客户端错误是否属于服务责任，后台重试产生的请求是否重复计数，都会改变结果。指标名称相同不代表口径相同。

延迟通常用满足阈值的良好事件比例或分位数表达。平均值会掩盖尾部等待，而单个高分位也可能忽略不同用户和接口的差异。关键路径可以有独立 SLI，但指标过多会使运营目标失去焦点。

资源利用率、队列长度和进程存活是诊断信号，不一定是用户 SLI。CPU 很高时服务仍可能正常，CPU 正常时依赖故障也可能让用户失败。内部信号适合解释原因，用户结果适合定义可靠性。

服务等级目标（SLO）规定某个时间窗口内 SLI 应达到的水平。例如目标不是抽象的“高可用”，而是明确哪些请求在滚动周期中应成功。目标需要足够严格以保护用户，也要留出系统变更和现实故障空间。

目标不能凭行业常见的百分比直接复制。用户工作流是否能重试、故障持续多久、数据能否补算、替代渠道是否存在，都会影响可接受水平。更高目标通常要求更多冗余、容量、测试和运营投入。

窗口可以是日历周期或滚动周期。日历窗口便于预算和复盘，滚动窗口更及时反映最近体验。短窗口对偶发故障敏感，长窗口反应较慢。团队需要选择与用户影响和决策节奏一致的窗口。

SLO 是内部工程目标，不等同于对外合同中的 SLA。SLA 可能包含责任、排除项和补偿条款，口径也可能更宽松。二者应建立明确映射，但不能混用名称掩盖差异。

目标小于百分之百时，目标之外的允许部分就是错误预算。它可以换算为失败事件比例、不可用时间或未满足新鲜度要求的数据量。错误预算不是故意制造故障，而是承认绝对可靠既不现实也可能不经济。

预算充足时，团队可以在既定风险控制下推进发布；预算快速消耗时，应减少高风险变更，把精力转向故障原因、容量和恢复能力。这样的规则把“稳定还是迭代”的争论连接到用户数据，而不是依赖临时意见。

预算政策要在故障前约定。哪些事件消耗预算，超支后暂停哪些发布，紧急安全修复如何处理，都应明确。若每次超支后才重新解释口径，错误预算不会形成可信约束。

只看当前合规与否可能发现问题太晚。燃烧率比较实际错误消耗速度与目标允许速度：燃烧率为一表示按预算均匀消耗，大于一表示若趋势持续会提前耗尽预算。

高燃烧率适合触发快速响应，但短时尖峰可能噪声较多；低速持续消耗对用户同样重要，却需要更长窗口才能确认。实践中可以组合短窗口和长窗口，兼顾快速故障与慢性退化。

告警应指向需要行动的用户影响。每个内部异常都分页会造成告警疲劳，而只在整个窗口超标后告警又太迟。燃烧率把告警阈值与预算后果连接起来，诊断指标随后帮助定位原因。

全站成功率达标时，某个地区、租户、设备或关键接口仍可能长期失败。总流量大的健康群体会稀释小群体问题。SLI 应按产品承诺和风险分段检查，必要时为关键路径建立单独目标。

分段不能无限增加。每个 SLO 都需要数据质量、所有者和响应策略。可以先用总体目标管理主服务，再用诊断面板观察区域和功能切片；只有具有独立用户承诺和行动方案的切片才提升为正式 SLO。

低流量服务的比例波动很大，单个失败就可能产生剧烈变化。此时事件计数、合成探测、时间到期和业务周期完成率可能比请求比例更稳定。

客户端、边缘代理和服务端看到的结果不同。请求在到达服务前失败时，服务端日志无法记录；服务端返回成功后客户端解析失败，也不会出现在服务成功率中。关键用户旅程可结合客户端遥测和合成监控。

指标采样、日志丢失、时钟偏差和重试去重都会改变 SLI。监控系统故障时不能默认服务健康。SLO 文档应记录数据源、查询、延迟、缺失处理和版本，使数字能够复核。

变更指标定义会造成时间序列断点。新旧口径应并行一段时间并标记切换日期，避免把计算变化误判为可靠性改善。

架构设计可以从 SLO 反推故障检测、超时、冗余、降级和恢复时间。若关键数据新鲜度目标很严，系统需要明确数据延迟和补偿机制；若尾部延迟重要，就要限制排队和慢依赖传播。

事故复盘应说明消耗了多少预算、影响哪些 SLI、监控何时发现以及哪些设计因素放大影响。只记录进程宕机时间，无法判断真正的用户损失。

SLO 也应定期复核。长期轻松达到可能说明目标过宽、指标没有覆盖真实痛点，或服务确实有余量；持续超标则可能是设计能力不足，也可能是目标脱离用户需求。调整必须有用户和成本依据，不能为了让报表变绿而修改。

服务等级目标的作用，是让可靠性成为有口径、有预算、有行动规则的工程约束。它不是一个展示数字，而是产品、开发和运维共同使用的决策合同。

Google：Site Reliability Engineering Books，https://sre.google/books/
Carnegie Mellon Software Engineering Institute：Reasoning About Software Quality Attributes，https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/