slo-implementation（SLO实施）Skill 是什么？如何落地错误预算？

SLO实施Skill：用 SLI、SLO 和错误预算，把「服务稳不稳」变成可衡量的数字

它解决什么问题：把「服务要稳」从口头承诺变成可测量、可报警、可决策的数字体系——用 SLI 度量、用 SLO 定目标、用错误预算管发布节奏。
它给的不是空泛方法论：技能内置了可直接改用的 PromQL 查询、Prometheus 记录规则、多窗口燃烧率告警规则、Grafana 仪表板结构和错误预算分级策略。
典型产出：一份可落地的 SLO 定义 YAML、一套记录与告警规则、一张看板结构图，以及周/月/季三级审查流程。
适合谁用：SRE、平台工程团队、后端与基础架构负责人，以及任何需要向业务方回答「我们的可靠性到底达标没有」的技术管理者。
上手成本：它是一份「框架 + 模板」型技能，安装门槛低，但要真正跑通，仍需你手头有指标数据源（技能内容围绕 Prometheus 生态展开）。

一、该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能基本信息：

项目	内容
中文名	SLO实施Skill
英文名	slo-implementation
技能ID	13211
技能定位	定义和实施 SLI、SLO 与错误预算的框架，用于建立可靠性目标、落地 SRE 实践、测量服务性能

它到底解决什么问题？

在没有这套体系之前，团队讨论「稳定性」往往是这样的场面：产品经理说「最近老出问题」，研发说「已经修得很快了」，运维说「告警太多看不过来」——谁都没说错，但没有人能拿出一个数字来对齐。这个技能要做的，就是把这段争论翻译成三句话：

SLI（服务级别指标）：我们实际测量到的可靠性是多少？
SLO（服务级别目标）：我们内部承诺要达到多少？
SLA（服务级别协议）：我们对外合同里写了什么？

技能内容明确给出了这三者的层次结构：SLA 在最上层（与客户的合同），SLO 在中间（内部可靠性目标），SLI 在最底层（实际测量）。很多团队出问题，恰恰是因为把这三层混为一谈——把对外合同的数字直接当内部目标，或者根本没有可测量的 SLI 就敢定 SLO。

「一键安装」的思路与步骤

AI 技能的安装（也就是把这份技能加载到你的 AI 客户端/平台中）通常遵循统一流程，具体命令与入口请以你所使用平台的官方说明为准：

确认前提：你的 AI 客户端或开发平台需支持「技能 / Skill」机制（能加载带有 SKILL.md 描述文件的技能包）。本技能的详情中包含 references/slo-definitions.md、references/error-budget.md 以及 assets/slo-template.md 等参考文件，说明它是一个带附属资料目录的完整技能包。
找到技能入口：在平台的「技能市场 / 技能管理 / 插件管理」界面中打开搜索，或使用平台提供的技能安装入口。
搜索并安装：用英文名 slo-implementation 搜索最为精准；如果平台支持按编号检索，也可以使用技能ID 13211。找到后点击安装 / 添加 / 启用。
本地导入方式（如平台支持）：将技能目录放入客户端的技能目录中，确保 SKILL.md 位于该目录根路径下，然后重启或刷新技能列表。
验证是否生效：安装完成后，向 AI 提一个该技能覆盖范围内的问题，例如「帮我为一个 HTTP API 设计可用性和延迟两类 SLI，并给出 99.9% 目标下的错误预算」。如果回答中出现了 SLI 计算公式、28 天窗口、错误预算百分比等内容，说明技能已被正确加载；如果回答仍然是泛泛而谈的「建议监控关键指标」，则说明技能未生效，需要回到第 2 步检查。

为什么叫「一键安装就能提效」？

因为这类技能把专家经验前置固化了。你不需要先读完一本 SRE 书、再去翻十几个博客拼规则，安装后直接提问就能拿到一份结构正确的草稿——复杂度从「从零设计」降到「审阅与微调」。

二、该技能的主要功能和特点

完整的 SLI 定义库：覆盖可用性 SLI（成功请求 / 总请求）、延迟 SLI（低于阈值的请求 / 总请求）、持久性 SLI（成功写入 / 总写入）三类最常见指标，并且直接给出可直接运行的 PromQL 表达式，而不是「请统计成功率」这种废话。
SLO 目标与停机时间换算对照：内置 99% / 99.9% / 99.95% / 99.99% 四档目标对应的每月、每年允许停机时间（例如 99.9% 对应每月 43.2 分钟、每年 8.76 小时）。这张表是说服业务方的利器——「我们要不要从 99.9% 提到 99.99%」这个问题，一旦换算成「允许停机从 43.2 分钟压缩到 4.32 分钟」，成本讨论立刻变得具体。
可执行的 SLO 定义模板：以 YAML 形式给出 slos 结构，包含 name、target、window、sli 四个关键字段，例如 API 可用性 99.9%、28 天窗口，以及 P95 延迟低于 500ms 的占比目标 99%。
错误预算计算与分级策略：给出 错误预算 = 1 - SLO目标 的核心公式，并配套一份按剩余预算比例分档的行动策略——100% 正常开发速度、50% 考虑推迟风险变更、10% 冻结非关键变更、0% 功能冻结专注可靠性。这让「预算」真的能约束工程行为，而不只是好看的数字。
Prometheus 记录规则生成能力：区分 sli_rules 与 slo_rules 两组记录规则，产出合规性（1/0）、剩余错误预算百分比、燃烧率等派生指标，命名规范统一（如 sli:http_availability:ratio）。
多窗口燃烧率告警：同时给出快速燃烧（14.4 倍速率、1 小时窗口，约 1 小时消耗 2% 预算）与慢速燃烧（6 倍速率、6 小时窗口，约 6 小时消耗 5% 预算）两类告警，并用长短窗口组合来压制误报——这是本技能最「实战」的部分，直接对应告警噪音治理。
Grafana 仪表板结构说明：给出「SLO 合规性 → 剩余错误预算 → SLI 趋势 → 燃烧率分析」的四段式布局，并附上「按当前燃烧率推算错误预算耗尽天数」的查询思路。
配套的审查节奏：把 SLO 从「设了就忘」变成运营动作——每周看合规性与趋势，每月看达成情况与事后分析，每季度看目标相关性并调整。
10 条最佳实践：从「从用户面向的服务开始」「不要追求 100%」，到「实施多窗口告警减少噪音」「用 SLO 进行优先级排序」，基本覆盖了新手最常踩的坑。

和普通工具比强在哪？ 普通的监控工具告诉你「现在有多少错误」，这个技能告诉你「这些错误相对于我们的承诺意味着什么、还剩多少额度、什么时候该停下来修而不是继续发版」。

三、如何使用该技能？

以下是一套从零到一的完整使用路径，每一步都给出可直接参考的输入示例与预期输出。

第 1 步：先描述服务，让 AI 帮你选 SLI

输入示例：

「我有一个面向 C 端的订单查询 HTTP API，日均请求 2000 万，用户最在意的是能不能打开、打开得快不快。帮我定义 SLI。」

预期输出：技能会引导你从可用性、延迟（可能还包括持久性，如果涉及写入）三类中选择，并给出对应的 PromQL 分子/分母结构。

第 2 步：确认指标数据是否可得

技能给出的 PromQL 默认基于 http_requests_total、http_request_duration_seconds_bucket、http_request_duration_seconds_count 这类常见指标名。如果你的实际指标名不同（例如带业务前缀），需要让 AI 帮你替换为真实指标名——这一步是落地成败的关键，别直接复制粘贴。

第 3 步：设定 SLO 目标与统计窗口

输入示例：

「可用性目标定 99.9%，统计窗口 28 天，帮我算一下这个目标下允许的停机时间和错误预算。」

预期输出：技能会给出错误预算 = 0.1%，以及对应的每月 43.2 分钟 / 每年 8.76 小时的停机额度，并提示「不要追求 100%」这一最佳实践。

第 4 步：生成 SLO 定义配置

让 AI 输出一份 YAML 结构，字段为 name / target / window / sli，可直接作为团队内的 SLO 声明文件使用。

第 5 步：生成 Prometheus 记录规则

要求 AI 输出两组规则：sli_rules（计算 SLI 比值）和 slo_rules（计算合规性、剩余错误预算、燃烧率）。注意技能建议的采样间隔为 SLI 规则 30s、SLO 规则 5m，可按实际采集压力调整。

第 6 步：配置多窗口燃烧率告警

输入示例：

「帮我写基于 99.9% 可用性 SLO 的燃烧率告警，要考虑误报问题。」

预期输出：快速燃烧告警（1 小时窗口与 5 分钟窗口同时超过 14.4 倍，持续 2 分钟触发，严重级别 critical）与慢速燃烧告警（6 小时与 30 分钟窗口同时超过 6 倍，持续 15 分钟触发，warning 级别），外加错误预算耗尽告警。

第 7 步：搭建仪表板

让 AI 输出 Grafana 面板规划：SLO 合规性当前值、剩余错误预算进度条、28 天 SLI 趋势图、燃烧率分析图。

第 8 步：建立审查节奏并落到流程

让 AI 帮你把每周、每月、每季度的审查项整理成会议议程或检查清单，明确「预算剩余多少时谁有权决定冻结发布」。

使用提示：技能内容中提到 assets/slo-template.md、references/slo-definitions.md、references/error-budget.md 等参考文件，以及 prometheus-configuration（指标采集）和 grafana-dashboards（可视化）两个相关技能——如果你的平台支持多技能组合，可以一并加载，形成「采集 → 目标 → 告警 → 可视化」的完整链路。

四、同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
SLO实施Skill（slo-implementation）	AI 技能形态的 SRE 方法论 + 规则模板库	SLI 定义与 PromQL、SLO 目标与停机时间换算、错误预算策略、Prometheus 记录规则、多窗口燃烧率告警、Grafana 看板结构、审查流程	需支持技能的 AI 客户端；无需额外部署；但需自备指标数据源	从 0 到 1 建立可靠性目标、告警噪音治理、以预算驱动发布决策	优势：开箱即用、结构化程度高、规则可直接改写；不足：偏方法论与模板，不负责实际部署与调参，需人工与真实环境对齐
云监控平台自带的托管 SLO 功能	云厂商一体化可观测性产品中的 SLO 模块	在平台内定义 SLO、自动计算预算、内建告警与看板	需已在对应云平台有监控数据；配置以控制台为主；具体能力与计费以官方说明为准	全栈已在同一云平台、希望少运维的团队	优势：与现有监控数据天然打通、免维护；不足：与平台绑定较强，跨云或自建环境迁移成本高，方法论引导相对少
开源 SLO 规则生成工具	从 SLO 声明自动生成 Prometheus 规则的命令行工具	声明式 SLO 定义、自动生成记录规则与告警规则	需自行部署维护、需熟悉 Prometheus 规则体系	已深度使用 Prometheus、追求 GitOps 化管理的团队	优势：纯声明式、易纳入版本管理、可自动化；不足：只解决「规则生成」一环，不提供目标选择、预算策略与审查流程的指导
全手工方案（内部文档 + 表格 + 手写规则）	团队自行沉淀的 SRE 规范文档	视团队水平而定，通常包含指标口径、目标列表、值班流程	零工具成本，但学习与试错成本高	小团队早期、临时性可靠性盘点	优势：完全贴合自身情况、无外部依赖；不足：依赖个人经验，容易遗漏错误预算、燃烧率、多窗口告警等关键设计，迭代慢

选型建议：如果你已经有一套 Prometheus 体系但缺方法论与模板，本技能性价比最高——它补的正是「怎么定目标、怎么算预算、怎么写不吵人的告警」这一段。如果你整个技术栈都在某家云上、追求零运维，托管 SLO 功能会更省事。如果你需要把 SLO 纳入 GitOps 流水线，可以把本技能产出的规则作为起点，再交给声明式工具做自动化。

五、该技能的典型应用场景与实际体验情况

场景一：SRE / 平台工程团队从 0 到 1 建立可靠性目标

角色与痛点：团队刚被要求「做 SRE」，但没人知道第一个 SLO 该怎么定。有人提议「全部定 99.99%」，被运维一句「那我们就别发版了」顶回来。
使用方式：先让 AI 列出核心用户路径，选定 2～3 个服务；用技能给出的换算表把候选目标翻译成允许停机时间；再让 AI 生成 SLI 查询与 SLO 定义 YAML。
体验：起步非常快，最大的价值是那张「99.9% = 每月 43.2 分钟」的对照表，它把抽象目标变成了所有人都能理解的资源额度，讨论立刻从立场之争变成数字之争。

场景二：告警噪音治理

角色与痛点：值班同学每天收到上百条告警，大部分是瞬时抖动，真正的事故反而被淹没，长期形成「告警疲劳」。
使用方式：让 AI 按技能给出的多窗口燃烧率模型重写告警——快速燃烧用 1h + 5m 双窗口同时超 14.4 倍才触发，慢速燃烧用 6h + 30m 同时超 6 倍才触发。
体验：这是本技能最见效的部分。长短窗口「与」逻辑能从机制上过滤掉单点抖动，而不是靠不断调阈值。注意事项是 for 持续时间与窗口长度需要结合自身流量规模微调，低流量服务上燃烧率指标波动会比较大。

场景三：用错误预算决定发布节奏

角色与痛点：研发负责人需要在「业务催上线」和「系统不稳定」之间做取舍，但缺乏客观依据，最后往往是谁嗓门大听谁的。
使用方式：把技能给出的四分档策略直接改造成团队公约——剩余预算 100% 正常发版、50% 推迟高风险变更、10% 冻结非关键变更、0% 功能冻结专注可靠性。
体验：把「要不要停」从一个情绪化决策变成一条预先约定好的规则，是这套体系最被低估的价值。注意策略必须提前和业务方达成一致并写入文档，事后才拿出来会引发抵触。

场景四：向管理层汇报可靠性现状

角色与痛点：技术负责人每季度要回答「我们的系统到底稳不稳」，但只有一堆零散的事故记录。
使用方式：按技能给出的四段式看板结构搭建视图，用「剩余错误预算」和「按当前燃烧率推算的耗尽天数」作为核心汇报指标，配合季度审查清单复盘目标是否仍然合理。
体验：预算剩余百分比是一个跨角色都能看懂的语言，比「可用性 99.93%」更有行动指引性。

整体上手体验：这个技能属于「读起来简单、用好需要动脑」的类型。前置知识门槛不高，但要求使用者对 Prometheus 指标命名和 PromQL 有基本概念，否则生成的规则无法直接落地。建议第一次使用时先用一个非核心服务练手，跑通一轮 28 天窗口的完整流程，再推广到关键服务。

六、该技能能为用户带来的价值

效率层面：把「查资料 → 设计指标体系 → 写 PromQL → 写记录规则 → 写告警规则 → 画看板」这一整条链路压缩成一次对话。以往这套动作往往需要查阅大量文档、反复试错，现在可以在一轮提问内拿到结构正确、命名规范、可直接改用的草稿，后续工作集中在「对齐真实指标名」和「微调阈值」上。

门槛层面：错误预算、燃烧率、多窗口告警这些概念，对没做过 SRE 的团队来说理解成本不低。技能把这些概念直接具象成 YAML 和 PromQL，让「先抄再懂」成为可行路径——先跑起来看到数据，再回头理解原理，比先读完理论再动手的路径短得多。

可量化的收益：技能内置的目标换算表本身就是一套现成的「成本语言」——把 99.9% 与 99.99% 的抉择换算成每月 43.2 分钟与 4.32 分钟的差距，帮助团队避免为「最后一分钟可用性」付出不合理的架构成本。错误预算分级策略则把「什么时候该停手」变成可执行的规则，减少无谓的争论成本。

长期价值：SLO 体系真正的价值不在于某一天的指标，而在于形成一个闭环——设定目标、持续测量、预算告警、定期审查、必要时调整。技能提供的周/月/季三级审查流程，正是把这个闭环固定成组织习惯的抓手。一旦这个习惯建立起来，可靠性讨论就有了共同语言，事故复盘也有了客观标尺，可靠性投入的优先级也能用预算数据来论证，而不是靠「感觉最近不太稳」。

七、常见问题 FAQ

Q1：这个技能怎么安装？收费吗？

按前文流程，在支持技能的 AI 客户端或平台中搜索英文名 slo-implementation 或技能ID 13211 即可找到并安装；本地导入方式则是把技能目录放入客户端的技能目录、确保 SKILL.md 在根路径下。至于是否收费、是否有额度限制，取决于你使用的平台与技能来源，请以官方说明为准。

Q2：一定要用 Prometheus 和 Grafana 吗？

技能内容中的 SLI 查询、记录规则、告警规则都基于 Prometheus 的指标与 PromQL 语法，可视化部分以 Grafana 仪表板结构呈现，所以这条路是最顺的。但它的核心价值——SLI/SLO/SLA 的层次、错误预算公式、分档策略、多窗口燃烧率思路——是方法论层面的，换成其他支持类似查询语言的监控体系，可以让 AI 帮你把 PromQL 改写成对应的查询语法。

Q3：SLO 目标应该定 99.9% 还是 99.99%？

技能给出的原则是「设置可实现的 SLO，不要追求 100%」，并建议综合考虑用户期望、业务需求、当前性能、可靠性成本和竞争对手基准。实操上，先看当前实际达到的水平，再在当前水平之上设一个需要努力但可达成的目标；同时用换算表确认对应的停机额度（99.9% 为每月 43.2 分钟，99.99% 为每月 4.32 分钟）是否是团队真的能承受和兑现的。

Q4：和云厂商自带的 SLO 功能怎么选？

如果你的监控数据已经集中在某一朵云上、希望少维护，托管 SLO 功能更省事；如果你需要一套能指导「怎么定目标、怎么设计不吵人的告警」的方法论和模板，并希望产出可以纳入代码仓库的规则文件，这个技能更合适。两者也可以组合：用技能设计体系与规则，再落到具体平台执行。

Q5：小团队也适合用吗？

适合，但要缩小范围。技能的第一条最佳实践就是「从用户面向的服务开始」——小团队不必一上来就覆盖所有服务，选一个最核心的用户路径、定义两三条 SLI（可用性和延迟）、配一条燃烧率告警就够了。关键是先把「测量—目标—预算—告警」这个小闭环跑通一轮，再逐步扩展，而不是一开始就求全。