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

SLO在小红书的探索与实践 姓名：韩奇祺 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 个人简介 韩奇祺 公司职位 小红书/可观测技术部 负责告警、大盘、服务监控相关研发工作目前从0-1负责SLO平台能力建设 为什么引入SLO 运营建设思路 目录平台能力及最佳实践 结果和展望 01 为什么引入SLO 稳定性现状:故障 故障 •故障数持续减少，但速度放缓，故障等级向低危转移，但极端故障风险依然存在 •某些场景故障收敛，有些实现了阶段性清零 •某些场景近期故障频发，主要来源于代码bug与系统设计历史债务问题，加之迭代加快带来的质量与稳定性风险 ->缺少非故障类型的稳定性目标牵引，缺少一种预算机制，去平衡功能迭代和稳定性之间的关系 MTTR •体现了针对故障的应急协同能力 •架构的容错和弹性 故障数 •结果，不可控因素多，受变更、容量等因素影响 •能代表问题发生与不发生，不能提现业 务质量 风险 •风险识别来自故障驱动居多 •一些稳定性风险依赖人工梳理 GOPS全球运维大会暨研运数智化技术峰会2024·上海站 稳定性现状:架构治理 架构治理 技术架构和链路随着业务的扩张成几何倍数变的复杂，上下游依赖之间稳定性改进困难。 业务之间需要明确好服务提供方和用户双方之间的责任和合作方式，握手和建立约束，给到上游一个明确可量化的能力表现预期，比如提供的服务质量需要保证99.99% MTTR 稳定性现状:服务劣化 服务劣化 服务质量开始劣化且劣化程度没有达到告警阈值的时，很难被感知到。在这种情况下提升告警阈值又会导致告警泛滥。 告警像是一个重度问题的急诊，服务劣化现象更像是亚健康的状态，是长周期的问题，基于影响面积去体现劣化程度，很难被告警发现。 SLO能够累记一定时间窗口的错误，计算的是累积值。 MTTR 为什么引入SLO 运作机制 什么是SLO SLI SLI（ServiceLevellndicator，服务等级指标）定义了一个指标，来描述一个服务对外提供的核心能力。比如延迟、成功率等 SLO SLO（ServiceLevelObjective，服务等级目标）定义了一个目标，来衡量一个SLI指标在一段时间内达到“好”的标准的比例。比如RT-P99<20ms，成功率大于99.99% SLA SLA（ServiceLevelAgreement，服务等级协议）是SLO衍生出来的协议，常用于商业上的协议：如果SLO目标没有完成，服务方要赔多少钱 SLO是在核心业务指标上的“精装修”，相比传统Metrics管理更加聚焦，SRE日常重点关注服务SLO相关指标，其他Metrics指标用于辅助问题发现和定位。 错误预算 当确立了SLI和SLO后，对于一个服务就能够计算出在时间窗囗内的错误预算，公式很简单，就是： 错误预算=单位时间内请求数(单位时间)*(1-SLO) 错误预算是指在一定时间范围内，系统或服务能够接受的错误率的上限。它是一项关键的性能指标，用于确保系统能够在可接受范围内提供稳定和高质量的服务 02 运营建设思路 定义业务SLO，度量和发现稳定性稳定，建立故障与SLO双规模式。以SLO牵引风险闭环和防劣化。 小红书故障响应体系 •北极星 •业务场景 •核心指标及告警 •故障诊断 •RCA故障平台 ->围绕业务场景，定义SLO 业务场景 •针对各业务场景与业务握手，对齐SLO •如何选择SLI指标 •怎么定制SLO目标 •SLO运营治理 =>不达标破线问题分析 =>建立周/月纬度的数据运营机制 SLO协同 通过核心业务场景定义SLO指标并向下拆解定义中台服务和基建服务SLO，实时看清楚公司核心服务稳定性水平 •构建不同维度SLO之间的关联关系，串联公司所有产品的稳定性关系，看到产品之间的相互影响的关系 •与用户体验数据打通，提升高可用工作对用 户体验的作用 SLO与故障 确立故障和SLO相辅相成的关系，建设故障与SLO的双规模式 •故障数据体现对事中能力建设的做工，推动大家在发生故障时的发现、应急、恢复等能力 •SLO体现整体高可用做工的结果，衡量所有时刻稳定性的做工，并利用数据让产品进行对稳定性建设的自驱 03 平台能力及最佳实践 下文将描述基于SLO的平台能力及相关的最佳实践 SLO能力矩阵 SLO架构-计算 •任务调度 任务分发数据源隔离 •查询与计算 •破线处理 破线分析，集成故障诊断 破线事件处理，聚合，写入MySQL •通知 打通告警中心和RCA平台 SLO架构-查询 •统一查询 屏蔽不同业务域、数据源的差异支持天、周、月粒度的数据聚合 •事件管理 破线事件及时间线标注、聚合 拉起RCA •平台能力 SLO大盘订阅通知风险识别 最佳实践-SLO全景 最佳实践-SLO运营大盘 SLO运营大盘，提供了不同视角、周期的SLO运营数据用于宏观的去看公司、业务线及业务场景的SLO情况 最佳实践-北极星指标 出现明显影响业务或用户体验的故障时候，故障发现层能及时产生报警； 北极星指标对应的场景会飘红，准确的指向出问题的业务场景 最佳实践-破线跟进 展示了各个场景的SLO统计数据，包括业务线和业务场景，业务线包含各个业务场景的SLO汇总数据，业务场景展示 各个业务指标的SLO 最佳实践-破线详情 展示某个业务SLO的详情信息，SLO、破线时间轴和破线事件列表，并提供破线事件的标注和合并的能力 最佳实践-破线处理 SLI破线:生成破线事件，并通知对应SRE和业务负责人 •针对破线事件，需要进行原因标注 •对于未知风险，进行风险治理和验证 SLO破线：会触发RCA，该破线事件在RCA平台产生一条SLO问题 •拉起对应的SRE和业务负责人，进行稳定性问题的跟进和治理 最佳实践-破线定位 以业务SLO驱动故障定位流程，借助于故障诊断能力，在SLO破线的时触发故障诊断，提供破线事件的原因 •破线时触发故障诊断进行根因分析，作为破线的诊断结果 •未来会基于SLO关联的指标元数据和业务拓扑，提供更加完整和精确的指标和拓扑元数据，辅助故障诊断 04 总结及展望 总结SLO建设中的进展和展望 建设思路 北极星指标 业务SLO 运营报表 破线事件 平台SLO SLO关联 取得的结果 •覆盖了8条业务线，5个中台基建，共99个场景的北极星指标覆盖，并产出SLO运营红黑榜等 •SLO共识：业务与基建、平台、算法等等之间协同问题，达成共识，基于SLO握手，并进行 问题和架构的治理 •平台能力 基于业务场景，实现从北极星/业务线/业务场景/破线事件的SLO产品建设 基于破线事件的OnCall机制 •风险识别：月均发现10+起RCA没发现的case，事件解决率100% 展望 平台侧 •业务拓扑 •故障诊断融合 •SLD/SLF 运营侧 •基于业务SLO的OnCall体系 •SLO依赖梳理 •SLO覆盖 展望-技术风险生态支撑 SLO作为关键指标，用于故障发现、风险拦截、故障诊断、应急协同等方向的关键指标判断 Thanks 高效运维社区DevOps时代 荣誉出品