可观测性与 SLO（深度工作流）

SLO 将工程工作与用户感知的可靠性联系起来。SLI 必须可从系统中测量，同时基于用户旅程。

何时提供此工作流

触发条件：

• 在未明确“针对什么”的情况下定义 99.9%
• 页面过多或过少；需要建立错误预算纪律
• 产品方希望推进功能，但稳定性持续下降

初始建议：

采用六个阶段：(1) 选择用户旅程，(2) 定义 SLI，(3) 设定 SLO 目标与时间窗口，(4) 错误预算策略，(5) 对预算消耗进行告警，(6) 回顾与迭代。确认指标栈和来自供应商的依赖项 SLO。

阶段 1：用户旅程

目标： 一旦中断就会产生重大影响的关键路径——如结账、登录、API 同步，而非“CPU 使用率低”。

输出

3–10 条用户旅程，按业务影响和发生频率排序。

退出条件： 每条旅程用一段话描述：用户意图 + 失败表现。

阶段 2：定义 SLI

目标： 在一段时间内，良好事件数 / 总事件数的比率——实现方式需明确。

示例

• 可用性：成功请求数 / 有效请求数（需明确定义“有效”）
• 延迟：响应时间低于 T ms 的请求占比

优秀的 SLI 特征

• 客观，且基数足够低，可可靠测量

退出条件： 提供 SLI 公式及数据来源（指标、日志、探针）。

阶段 3：SLO 目标与时间窗口

目标： 目标值（例如每月 99.9%）意味着允许的故障分钟数——必须明确表达。

实践建议

• 采用滚动 30 天作为常见时间窗口，与发布节奏对齐
• 分层服务：并非所有服务都需要相同的 SLO

退出条件： 发布一张表格：旅程 → SLI → 目标 → 时间窗口。

阶段 4：错误预算策略

目标： 当预算处于健康状态或耗尽时，应采取的行动策略。

策略建议

• 预算健康 → 推送新功能；预算不足 → 停止高风险变更，专注稳定性
• 预算快速消耗时启动升级流程（多时间窗口告警）

退出条件： 策略文档已撰写，并获得产品团队签字确认。

阶段 5：预算消耗告警

目标： 告警关注预算消耗速率，而非每个微小波动——使用谷歌风格的 SLO 告警时，采用多时间窗口 + 多消耗速率模式。

实践建议

• 快速消耗 = 立即通知；缓慢消耗 = 创建工单/跟踪处理

退出条件： 告警规则已与运行手册（runbooks）关联。

阶段 6：回顾与迭代

目标： SLO 会随架构演进而漂移——需每季度回顾一次，根据数据调整目标。

最终检查清单

• [ ] 用户旅程与 SLI 与真实用户痛点相关
• [ ] 目标设定合理，考虑依赖关系与成本
• [ ] 错误预算策略已与产品团队达成一致
• [ ] 告警聚焦于预算消耗，避免因症状噪音引发干扰
• [ ] 已安排定期回顾周期

有效引导建议

• 将 99.9% 转化为每月允许的故障分钟数。
• 区分 SLA（合同承诺）与 SLO（内部目标）——不要混淆。
• 依赖项 SLO 限制了你能承诺的范围——尽早暴露这一点。

处理偏差情况

• 尚无指标数据：可先使用代理 SLI（合成探针），逐步完善可观测性建设。
• 批处理系统：以事件处理延迟作为 SLI，而非 HTTP 请求。