SRE 实战手册五案例落地 SLO 时还要考虑哪些因素对应课程「05案例落地 SLO 时还需要考虑哪些因素」。前面三讲是方法这篇是真实世界的褶皱。一、方法对了为什么一落地就变形第 03、04 讲我们把 SLI/SLO/错误预算讲得很顺选 RED、定 99.9%、算预算。可真到悦购电商这种真实业务里立刻冒出一堆方法管不了的问题结账接口 99.9%那商品详情页要不要也 99.9%大促期间流量翻 10 倍SLO 还按平时算吗支付依赖了第三方它挂了我们算不算我们超 SLO移动端弱网超时算谁的错误课程这一讲的价值就是把定 SLO从一道数学题还原成一道带约束的工程决策题。二、因素 1SLO 要分层不要一个目标管全家真实系统是一棵树不是一条线。我们给悦购分了三层层级用户动作SLISLO核心链路下单结账checkout 成功率99.9%重要链路加购、查商品成功率 / p9999.5%次要链路评价、推荐成功率99.0%核心链路才配 99.9%次要链路宽松些。把所有接口都定 99.99%等于没有重点团队会被均摊的严苛拖死。三、因素 2区分我们的错和别人的错这是最容易吵起来的点。结账依赖支付网关支付网关抖动导致我们返回 500——如果直接把 500 算进我们的错误预算支付一抖我们就被误杀SLO 失去意义。如果完全不算我们又可能用是支付的锅掩盖自己重试/降级没做好的事实。实践里的分法也是我们demo_app.py的建模思路直接错误我们代码/配置/容量问题导致的失败计入预算依赖方已明确声明不可控、且我们没有兜底手段的部分单独建依赖可用性看板不计入本服务 SLO但计入依赖风险复盘。换句话说不算进预算 ≠ 不管理。只是管理的方式从扣预算变成做降级/多活/商务 SLA 约束。四、因素 3SLO 要随业务节奏调参不是刻在石头上大促期间悦购的结账 QPS 从 200 飙到 2000。这时候如果 SLO 不变稍微一点容量余量不足就疯狂烧预算团队整周都在救火业务侧却正赚得欢。更合理大促前主动调低 SLO 目标如临时到 99.5%把多出来的预算花在承接流量上大促后再调回。错误预算在这里体现了它的本质——它是风险的额度可以按计划花掉。关键是调参动作要提前、透明、共识而不是出了事再改目标线那是作弊。五、因素 4测量口径要抗偏见课程特别点了一个隐蔽坑SLI 的算法本身会被人为优化从而失去意义。比如你用HTTP 5xx 率当 SLI研发可能加个全局 try-catch 把所有异常转成 200 返回——5xx 率瞬间变 0SLO 完美达标用户照样下单失败。对策我们 Demo 的设计也遵循SLI 尽量用用户侧可感知的信号如下单是否真的生成了订单号而不是服务端有没有抛异常。多 SLI 交叉验证成功率 时延 业务埋点订单创建数三者对不上就说明有人在对指标动手脚。六、因素 5SLO 是最小可用共识先有再迭代很多团队卡在我们还没想清楚 SLO 该定多少所以先不定。课程的态度很明确先定一个不完美但各方签字的跑一个月用真实数据回头调。我们的 99.9% 不是算出来的真理是拍的一个够用起点。等错误预算跑出真实燃烧曲线下个季度再校准——这才是 SLO 该有的样子。七、把分层 SLO落进配置对应到deploy/slo_rules.yml核心链路单独成组、阈值更严次要链路建独立记录规则。节选-record:job:checkout_errors:rate1hexpr:|sum(rate(sre_http_requests_total{endpointcheckout,status500}[1h])) / sum(rate(sre_http_requests_total{endpointcheckout}[1h]))# 次要链路如 products可用更宽松的阈值单独评估八、小结与思考题落地 SLO 的五个现实褶皱分层、分清责任、随节奏调参、抗偏见测量、先有再迭代。思考题把你系统的接口列出来强制分成核心 / 重要 / 次要三层给每层先拍一个 SLO。你会发现最难的不是算数而是说服各方在核心层那行签字——因为签了字就意味着超了要担责。下一篇进入最紧张的部分故障发生了怎么发现、怎么处理。
