SRE 实战手册三SRE 切入点选 SLI、定 SLO对应课程「03SRE 切入点选择 SLI设定 SLO」。这是整套方法论里最该先做对的一步。一、SLI / SLO / SLA三个缩写先分清课程一上来就把这三个极易混淆的概念掰开SLIService Level Indicator指标对系统某方面表现的量化测量。比如过去 5 分钟结账接口的成功率。它是事实。SLOService Level Objective目标你给 SLI 定的目标值。比如结账成功率 ≥ 99.9%。它是承诺对自己/对协作方。SLAService Level Agreement协议带违约后果的对外承诺通常写进合同违了要赔钱。它是法律/商务层面的。一句话SLI 是尺子SLO 是红线SLA 是带罚则的红线。SRE 日常主要和 SLI、SLO 打交道SLA 更多是商务动作但它的数值通常要严于SLO给自己留余量。二、怎么选 SLIRED 与 USE 两张王牌SLI 不是越多越好选错指标比没指标更糟。业界有两套成熟方法课程里也重点提及RED面向请求型服务如 Web/APIRate吞吐量QPSErrors错误率Duration时延分布看 p99别只看平均USE面向资源型组件如 CPU/磁盘/缓存Utilization利用率Saturation饱和度队列长度、等待数Errors错误数我们的悦购电商 Demo 是典型的请求型服务所以直接用 RED。看deploy/demo_app.py里/metrics暴露的指标# HELP sre_http_requests_total 各接口请求总数按状态码 sre_http_requests_total{nodeecs-584a-0002,endpointcheckout,status200} 18203 sre_http_requests_total{nodeecs-584a-0002,endpointcheckout,status500} 9 # HELP sre_http_request_duration_seconds 请求耗时直方图 sre_http_request_duration_seconds_bucket{node...,endpointcheckout,le0.2} 17980 sre_http_request_duration_seconds_bucket{node...,endpointcheckout,leInf} 18212这就是一组现成的 SLI 原料。三、怎么定 SLO四个实操原则课程给了很落地的建议结合实验我总结成四条1. SLO 要落在用户真的在乎的指标上不要拿 CPU 利用率定 SLO用户不在乎你 CPU 多少要拿结账成不成功加购快不快定。我们选checkout接口的成功率作为核心 SLO 对象——因为它直接对应收入和用户体验。2. SLO 目标值要够用且可信不是越高越好张口就来我们要 100% 可用是新手最容易犯的错。100% 意味着零容错工程上不可能团队也会被自己定的假目标压垮。我们定为99.9%30 天窗口。为什么不是 99.99%因为 99.99% 对应每月只允许 ~52 分钟错误预算对悦购这种非核心金融的系统来说过于严苛会严重拖慢迭代。SLO 是成本和风险的折中不是 KPI 越高越好看。3. SLO 要配套如何测量的口径SLO 不写口径 没有 SLO。我们的口径SLI 1 - (checkout 返回 5xx 的请求数 / checkout 总请求数) 窗口 滚动 30 天 测量源 Prometheus: sum(rate(checkout 5xx)) / sum(rate(checkout 全部))4. SLO 是共识不是 SRE 单方面宣布这点极其关键也是下一讲错误预算的伏笔SLO 必须研发、产品、SRE 三方认可。否则 SRE 拿着你超 SLO 了去卡发版研发会觉得你在耍官威。四、把 SLO 写进可执行的配置光写文档不够要落到告警规则里。看deploy/slo_rules.yml的一段这是生产级 Prometheus 版配置本实验因机子公网仅 5Mbit、Prometheus 二进制直连 GitHub 下载近乎停滞改为用等价的零依赖sre_monitor.py跑通同一套语义见deploy/README.mdgroups:-name:slo-checkoutrules:-record:job:checkout_errors:rate1hexpr:|sum(rate(sre_http_requests_total{endpointcheckout,status500}[1h])) / sum(rate(sre_http_requests_total{endpointcheckout}[1h]))这条记录规则持续算过去 1 小时结账错误率它就是我们的 SLI 在 Prometheus 里的化身。后面接燃烧速率告警第 04、06 讲展开。五、常见坑坑 1SLI 选了用户不在乎的指标→ 团队为CPU 达标狂欢用户为下单失败骂街。坑 2SLO 定到 100%→ 要么造假要么团队崩溃。坑 3只有 SLO 数字没有测量口径→ 出事互相甩锅你说的成功率算法和我理解的不一样。坑 4SLO 由 SRE 拍脑袋→ 没有共识后面错误预算机制根本推不动。六、小结与思考题SLI 是尺子、SLO 是红线、SLA 是带罚则的红线。请求型服务用 RED资源型组件用 USE。SLO 要落在用户在乎的指标上、目标值够用即可、必须写清测量口径、必须是多方共识。思考题把你负责的系统里最该被 SLO 守护的那一个用户动作写出来再写下它的 SLI 公式和窗口——你会发现光是怎么算成功这一件事团队内部可能就有三种理解。下一篇我们讲让 SLO 真正活起来的机制错误预算。
SRE 实战手册三SRE 切入点选 SLI、定 SLO对应课程「03SRE 切入点选择 SLI设定 SLO」。这是整套方法论里最该先做对的一步。一、SLI / SLO / SLA三个缩写先分清课程一上来就把这三个极易混淆的概念掰开SLIService Level Indicator指标对系统某方面表现的量化测量。比如过去 5 分钟结账接口的成功率。它是事实。SLOService Level Objective目标你给 SLI 定的目标值。比如结账成功率 ≥ 99.9%。它是承诺对自己/对协作方。SLAService Level Agreement协议带违约后果的对外承诺通常写进合同违了要赔钱。它是法律/商务层面的。一句话SLI 是尺子SLO 是红线SLA 是带罚则的红线。SRE 日常主要和 SLI、SLO 打交道SLA 更多是商务动作但它的数值通常要严于SLO给自己留余量。二、怎么选 SLIRED 与 USE 两张王牌SLI 不是越多越好选错指标比没指标更糟。业界有两套成熟方法课程里也重点提及RED面向请求型服务如 Web/APIRate吞吐量QPSErrors错误率Duration时延分布看 p99别只看平均USE面向资源型组件如 CPU/磁盘/缓存Utilization利用率Saturation饱和度队列长度、等待数Errors错误数我们的悦购电商 Demo 是典型的请求型服务所以直接用 RED。看deploy/demo_app.py里/metrics暴露的指标# HELP sre_http_requests_total 各接口请求总数按状态码 sre_http_requests_total{nodeecs-584a-0002,endpointcheckout,status200} 18203 sre_http_requests_total{nodeecs-584a-0002,endpointcheckout,status500} 9 # HELP sre_http_request_duration_seconds 请求耗时直方图 sre_http_request_duration_seconds_bucket{node...,endpointcheckout,le0.2} 17980 sre_http_request_duration_seconds_bucket{node...,endpointcheckout,leInf} 18212这就是一组现成的 SLI 原料。三、怎么定 SLO四个实操原则课程给了很落地的建议结合实验我总结成四条1. SLO 要落在用户真的在乎的指标上不要拿 CPU 利用率定 SLO用户不在乎你 CPU 多少要拿结账成不成功加购快不快定。我们选checkout接口的成功率作为核心 SLO 对象——因为它直接对应收入和用户体验。2. SLO 目标值要够用且可信不是越高越好张口就来我们要 100% 可用是新手最容易犯的错。100% 意味着零容错工程上不可能团队也会被自己定的假目标压垮。我们定为99.9%30 天窗口。为什么不是 99.99%因为 99.99% 对应每月只允许 ~52 分钟错误预算对悦购这种非核心金融的系统来说过于严苛会严重拖慢迭代。SLO 是成本和风险的折中不是 KPI 越高越好看。3. SLO 要配套如何测量的口径SLO 不写口径 没有 SLO。我们的口径SLI 1 - (checkout 返回 5xx 的请求数 / checkout 总请求数) 窗口 滚动 30 天 测量源 Prometheus: sum(rate(checkout 5xx)) / sum(rate(checkout 全部))4. SLO 是共识不是 SRE 单方面宣布这点极其关键也是下一讲错误预算的伏笔SLO 必须研发、产品、SRE 三方认可。否则 SRE 拿着你超 SLO 了去卡发版研发会觉得你在耍官威。四、把 SLO 写进可执行的配置光写文档不够要落到告警规则里。看deploy/slo_rules.yml的一段这是生产级 Prometheus 版配置本实验因机子公网仅 5Mbit、Prometheus 二进制直连 GitHub 下载近乎停滞改为用等价的零依赖sre_monitor.py跑通同一套语义见deploy/README.mdgroups:-name:slo-checkoutrules:-record:job:checkout_errors:rate1hexpr:|sum(rate(sre_http_requests_total{endpointcheckout,status500}[1h])) / sum(rate(sre_http_requests_total{endpointcheckout}[1h]))这条记录规则持续算过去 1 小时结账错误率它就是我们的 SLI 在 Prometheus 里的化身。后面接燃烧速率告警第 04、06 讲展开。五、常见坑坑 1SLI 选了用户不在乎的指标→ 团队为CPU 达标狂欢用户为下单失败骂街。坑 2SLO 定到 100%→ 要么造假要么团队崩溃。坑 3只有 SLO 数字没有测量口径→ 出事互相甩锅你说的成功率算法和我理解的不一样。坑 4SLO 由 SRE 拍脑袋→ 没有共识后面错误预算机制根本推不动。六、小结与思考题SLI 是尺子、SLO 是红线、SLA 是带罚则的红线。请求型服务用 RED资源型组件用 USE。SLO 要落在用户在乎的指标上、目标值够用即可、必须写清测量口径、必须是多方共识。思考题把你负责的系统里最该被 SLO 守护的那一个用户动作写出来再写下它的 SLI 公式和窗口——你会发现光是怎么算成功这一件事团队内部可能就有三种理解。下一篇我们讲让 SLO 真正活起来的机制错误预算。
