SLO在小红书的探索与实践 - 韩奇祺

研报总结

1. 引入SLO的原因

• 稳定性现状：

  • 故障数量持续减少，但增速放缓，故障等级向低危转移。
  • 部分场景已实现阶段性清零，但某些场景近期故障频发，主要源于代码bug和系统设计历史债务。
  • MTTR（平均修复时间）反映应急协同能力，但受变更、容量等因素影响，难以全面评估业务质量风险。

• 架构治理：

  • 随着业务扩张，架构变得越来越复杂，上下游依赖之间的稳定性改进困难。
  • 业务之间需要明确服务提供方和服务用户之间的责任和合作方式，以确保服务的质量。

• 服务劣化：

  • 服务质量开始劣化，但未达到告警阈值时难以被感知。
  • 基于SLO可以累计一定时间窗口的错误，更好地反映服务稳定性。

2. 运营建设思路

• 定义业务SLO：

  • 通过业务场景定义SLO，确保服务质量和稳定性。
  • 定义SLI（服务级别指标）、SLO（服务级别目标），并通过SLO计算错误预算，确保系统在可接受范围内提供稳定服务。

• 故障与SLO双规模式：

  • 构建故障与SLO的双规模式，通过故障数据反映事中能力，通过SLO衡量整体稳定性。

3. 平台能力及最佳实践

• SLO能力矩阵：

  • 计算：任务调度、数据源隔离、查询与计算、破线处理、通知。
  • 查询：统一查询、事件管理、平台能力（SLO大盘、订阅通知、风险识别）。

• 最佳实践：

  • 北极星指标：故障发生时及时报警，准确指向问题业务场景。
  • 破线跟进：展示各场景的SLO统计数据，提供破线事件的详细信息。
  • 破线处理：生成破线事件，通知相关人员进行原因标注和风险治理。
  • 破线定位：以业务SLO驱动故障定位流程，提供根因分析和故障诊断能力。

4. 取得的结果

• 覆盖范围：

  • 覆盖8条业务线、5个中台基建，共99个场景的北极星指标。
  • 产出SLO运营红黑榜。

• 共识与治理：

  • 达成业务与基建、平台、算法等之间的共识，基于SLO握手，进行问题和架构治理。

• 平台能力：

  • 实现从北极星/业务线/业务场景/破线事件的SLO产品建设。
  • 基于破线事件的OnCall机制。

• 风险识别：

  • 月均发现10+起RCA未发现的案例，事件解决率为100%。

5. 展望

• 平台侧：

  • 业务拓扑、故障诊断融合。
  • SLI/SLF运营侧：基于业务SLO的OnCall体系、SLO依赖梳理、SLO覆盖。

• 技术风险生态支撑：

  • SLO作为关键指标，用于故障发现、风险拦截、故障诊断、应急协同等方向的关键指标判断。