小团队的错误预算：现实的 SLO 与例行

为什么小团队要尽早有错误预算

小团队之所以能快速发布，是因为必须快速。风险通常不是一次戏剧性的停机，而是同样的小问题反复出现：不稳定的注册、偶尔失败的结账、某次部署偶尔导致某个页面出问题。每个问题都偷走工时，削弱信任，把每次发布变成抛硬币。

错误预算为小团队提供了一种简单的方式，让他们可以在不假装可靠性会“自然而然”出现的前提下继续快速推进。

SLO（服务等级目标）是对用户体验的明确承诺，用一个时间窗口内的数字表示。例如：“过去 7 天内，成功结账率至少 99.5%。”错误预算就是承诺中允许的“坏”部分。如果你的 SLO 是 99.5%，那么你的每周预算就是 0.5% 的失败结账。

这不是追求完美，也不是为了做形象工程。它不是繁重的流程、无休止的会议或没人更新的表格。它是一种就“足够好”达成共识、注意偏离并冷静决定下一步做什么的方法。

从小处开始：选 1 到 3 个面向用户的 SLO，绑定到最重要的用户路径，使用你已有的信号来衡量（错误、延迟、失败的支付），每周做一次简短的审查，看预算消耗并选择一项后续行动。习惯比工具更重要。

用通俗话说的 SLO、SLI 与错误预算

把可靠性想成一项饮食计划。你不需要完美的每一天。你需要目标、衡量方式和现实生活的容错量。

SLI（服务等级指标）是你监视的数字，比如“成功的请求百分比”或“p95 页面加载时间低于 2 秒”。SLO 是该数字的目标，比如“99.9% 的请求成功”。错误预算就是你可以偏离 SLO 的量而仍然算在轨道上。

举例：如果你的 SLO 是 99.9% 的可用性，那么你的预算是 0.1% 的停机时间。在一周（10,080 分钟）里，0.1% 大约是 10 分钟。这并不意味着你应该刻意“用掉”这 10 分钟，而是当你消耗它时，你是在有意识地用可靠性换取速度、实验或功能工作。

价值在于：把可靠性变成决策工具，而不是单纯的报告。如果你大部分预算在周三就烧完了，你就暂停有风险的改动并修复正在出问题的部分。如果你几乎没有消耗预算，你就可以更有信心地上线更多功能。

并非所有东西都需要相同的 SLO。面向公众的客户应用可能需要 99.9%。内部管理工具通常可以更宽松一些，因为影响范围更小、注意的人更少。

选择要保护的内容：用户真正注意到的那几件事

不要一开始就测量所有东西。先保护用户判断你产品是否可用的那些关键时刻。

选 1 到 3 条最关键的用户路径。如果这些路径稳了，大多数其他问题会显得次要。好的候选项包括首次接触（注册或登录）、关乎钱的时刻（结账或升级）和核心操作（发布、创建、发送、上传或关键 API 调用）。

用通俗的语言写下“成功”是什么意思。除非你的用户是开发者，否则避免用“200 OK”一类的技术术语。

几个可以改编的示例：

• 注册：用户提交表单后在 X 秒内进入应用，且未看到错误。
• 结账：支付完成，显示确认页，且用户不会被重复扣款。
• 发布 / 运行任务 / API 调用：操作完成且用户看到预期结果。

选择与你变更速度匹配的测量窗口。每天发布且想要快速反馈时，7 天滚动窗口很合适；发布不那么频繁或数据噪声较多时，28 天窗口更稳。

早期产品有一些限制：流量可能很低（一次不良部署就会严重影响数据）、流程变化快、遥测通常比较薄弱。没关系。先用简单的计数（尝试数 vs 成功数）。当用户路径本身基本稳定后再细化定义。

为早期产品设定现实的 SLO

从你今天发布的内容出发，而不是你希望拥有的一切。先用一到两周时间获取基线数据：关键旅程的成功率和失败率。用真实流量（如果有的话）。如果没有，就用自测、支持工单和日志。你只是要搭建对“正常”的大致认知。

你的第一个 SLO 应该是你大多数周都能达到、同时还能继续发布的那个。如果当前基线是 98.5%，不要设 99.9% 然后抱着侥幸心理。设在 98% 或 98.5%，然后再逐步收紧。

延迟指标很诱人，但早期可能会分散注意力。许多团队最开始更适合先用成功率 SLO（请求不出错完成）。当用户明显能感觉到延迟且你有足够稳定的数据时，再加入延迟类 SLO。

一个有帮助的格式是每条旅程一句话：谁、什么、目标、时间窗口。

• 新用户注册：7 天滚动窗口内，98.5% 的注册尝试成功。
• 付费用户结账：30 天滚动窗口内，99.0% 的支付成功。
• 活跃用户加载主页：7 天滚动窗口内，99.0% 的页面加载成功。

对账单和认证等涉及信任和金钱的时刻使用更长的窗口；日常流程用短一些的窗口。当你可以轻松满足某个 SLO，就把它稍微抬高一点，然后继续推进。

决定哪些事故算数、哪些可以忽略

当每次小插曲都变成火警时，小团队会耗掉大量可靠性时间。目标很简单：用户能感知到的痛点会消耗预算；其他问题按正常工作处理。

一小套事故类型就够了：完全中断、部分中断（某个关键路径失效）、性能退化（能用但很慢）、不良部署（发布导致失败）、和数据问题（错误、丢失、重复）。

贴在便签上的严重性等级

把等级保持小而实用，每次都用它。

• Sev1：大量用户无法完成核心旅程，或数据面临风险。立刻中断手头工作。
• Sev2：部分用户受影响或核心路径不可靠。当天修复或安排到下一个工作日优先处理。
• Sev3：小问题或内部不便。记录并继续。

决定哪些事情算进预算。把用户可见的失败当作支出：损坏的注册或结账、用户感知到的超时、阻断旅程的 5xx 峰值。计划内维护如果提前通知用户且应用在那段时间内按预期表现，则不计入预算。

一个能结束大多数争论的规则：如果真实的外部用户会注意到并且无法完成受保护的旅程，那就计入预算。否则不计入。

这个规则也能涵盖常见的灰色地带：第三方中断只有在破坏你用户旅程时才计入，低流量时段如果用户受到影响也计入，内部测试人员不计入，除非内部使用就是主要使用场景。

用轻量信号跟踪预算消耗

目标不是完美测量，而是一个共享且可复现的信号，告诉你何时可靠性正在变得昂贵。

对每个 SLO 选一个“事实来源”并坚持使用：监控面板、应用日志、合成检查命中某个端点，或单一指标如每分钟成功结账数。如果你后来改变测量方法，写下变更日期并把它当作重置，这样不会出现“苹果与橘子”的比较。

告警应反映预算消耗，而不是每次小毛刺。短时峰值可能很烦人，但如果只影响月度预算的一小部分，就不应该吵醒任何人。有一个简单且有效的模式：对“快速消耗”告警（你正处于一天内烧掉一个月预算的轨迹）和对“慢速消耗”告警（大约一周会烧完）的较软告警。

保留一个极小的可靠性日志，这样你就不会只靠记忆。每次事故一行就够：日期和持续时间、用户影响、可能原因、你改了什么、后续负责人和截止日期。

示例：两人小队为移动应用发布新 API。他们的 SLO 是“99.5% 的请求成功”，用一个计数器衡量。一次不良部署把成功率在 20 分钟内拉低到 97%。触发快速消耗告警，他们回滚，后续工作是“在部署前增加金丝雀检查”。

每周可靠性例行：20 分钟，同一时间、同一笔记

你不需要庞大的流程。你需要一个小习惯，让可靠性保持可见而不占用太多构建时间。20 分钟的检查足够，因为它把所有事情都归结为一个问题：我们是不是比计划更快地在消耗可靠性？

每周固定同一时间，保持一份共享笔记（追加而非重写）。一致性比细节重要。

一个简单议程：

• 预算扫一眼：每个 SLO 的剩余预算和造成消耗的最大原因。
• 新事故：每项一行（发生了什么、何时、用户影响）。
• 后续事项：挑 1–3 个你们真的会完成的行动。
• 承诺：分配负责人和截止日期，然后准时结束。

在后续事项和承诺之间，决定本周的发布规则并保持简单：

• 正常：按计划发布。
• 谨慎：继续发布，但避免在受影响区域做有风险的改动。
• 冻结：暂停某一区域的改动，直到顶级问题修好。

如果你的注册流程出现了两次短暂停机并烧掉大部分预算，你可能只冻结注册相关改动，同时仍发布不相关的工作。

把预算转成不戏剧化的路线图决策

错误预算只有在它改变你下周的工作时才有价值。重点不是完美的正常运行时间，而是一个清晰的决策方式：我们是上线功能，还是还债可靠性？

一句可以当众说出的策略：

• 预算健康时：继续发布，并修复已知的单个最严重的可靠性问题。
• 预算快速消耗时：暂停非必要的功能开发，把这一周用于消除主要故障模式。
• 预算耗尽时：把可靠性工作当作路线图，直到回到可接受范围。

这不是惩罚，而是一个公开的权衡，让用户不会为今天的快速迭代在未来买单。

当你降速时，避免模糊的任务比如“提高稳定性”。选择能改变下一个结果的改动：加保护措施（超时、输入校验、速率限制）、完善会捕获该类错误的测试、让回滚变得容易、修复最常见的错误来源，或为某个用户旅程增加一个告警。

把报告和责备分开。奖励快速的事故记录，即便细节混乱。唯一真正糟糕的事故报告是那种迟到的、没人记得发生了什么的报告。

小团队常掉入的陷阱

常见陷阱之一是第一天就设定金光闪闪的 SLO（99.99% 听起来很好），然后现实来临时悄悄忽视它。你的起步 SLO 应该是当前人员和工具能达到的，否则它会变成背景噪声。

另一个错误是测错东西。团队盯着五个服务和一个数据库图表，却错过了用户真正感受的旅程：注册、结账或“保存更改”。如果你不能从用户视角用一句话解释 SLO，它可能太内部化了。

告警疲劳会把修生产问题的那个人耗垮。如果每次小峰值都把人叫醒，告警就成了“正常”，真正的火警反而被忽视。只对用户影响进行呼叫，其他问题走日常查看流程。

一个更安静的杀手是计数不一致。某周你把两分钟的变慢算作事故，下周又不算。这样预算就变成争论而不是信号。把规则写下来并持续一致地执行。

有用的护栏：

• 从每个关键用户旅程一个 SLO 开始，而不是按组件分开。
• 设一个你大多数周能达成的 SLO，之后再逐步收紧。
• 只在用户受影响时发出告警。
• 使用简单的事故定义并每次一致应用。
• 把事后分析聚焦在“是什么让这事发生”，而不是“谁做的错”。

如果一次部署让登录功能挂了 3 分钟，每次都要计数，即便修得很快。一致性让预算变得有用。

10 分钟可执行的快速清单

设定 10 分钟计时器，打开共享文档，回答这五个问题：

• 哪 1 到 3 条用户旅程是你不能承受其中断的？
• 对每条旅程，你能写出一句带时间窗口的 SLO 吗？
• 你们是否就什么算事故达成一致，并约定谁在 24 小时内记录？
• 你是否看了最近 7 天并基于影响（而非烦恼）选出 1–3 项后续？
• 如果预算很低，你有简单的发布规则吗？

如果你暂时无法测量某件事，先用一个能迅速看到的代理：失败的支付、500 错误或标记为“结账”的支持工单。之后再替换为更精确的指标。

示例：两人小队本周看到三条“无法重置密码”的消息。如果密码重置是受保护的旅程，那就是一个事故。他们写下一条短记录（发生了什么、多少用户、他们做了什么）并选一个后续：为重置失败添加告警或增加重试机制。

示例：两人创业团队如何用错误预算保护一个功能

Maya 和 Jon 两人创业，周五发布。他们节奏快，但首批付费用户关心一件事：能否创建项目并邀请队友而不中断？

上周他们遇到一次真正的中断：一次错误的迁移导致“创建项目”失败了 22 分钟。他们还有三次“慢但未挂”的时段，页面旋转 8 到 12 秒。用户抱怨，但团队争论慢是否算作“宕机”。

他们选定一条旅程并把它量化：

• 旅程 SLO： 创建项目在 3 秒内成功，99% 的命中率，按周统计。
• 事故定义： 若成功率在 10 分钟内低于 97%，或 p95 延迟在 15 分钟内高于 5 秒，则视为事故并写短记录。

周一他们做 20 分钟例会。固定时间、同一文档。他们回答四个问题：发生了什么、烧了多少预算、有什么重复、以及哪一项单一改动能防止重复。

权衡变得很明显：中断加上慢响应烧掉了大部分周预算。所以下周的“一个大功能”变成“加上数据库索引、让迁移更安全，并对创建项目失败添加告警”。

结果不是完美的可靠性，而是更少重复问题、更清晰的去/否决决策，以及更少的深夜抢修，因为他们提前同意了什么算“够糟糕”。

下一步：从小做起并保持闭环短小

选一条用户旅程并为它做一个简单的可靠性承诺。错误预算在无趣且可复现时效果最好，而不是在追求完美时。

从一个 SLO 和一次每周例会开始。如果一个月后还觉得轻松，再加第二个 SLO。感觉沉重就缩小范围。

把数学保持简单（按周或按月）。把目标设为与你当前状态相匹配。写一页的可靠性说明，回答这些问题：SLO 及其如何衡量、什么算事故、本周谁负责、何时检查、当预算过快被消耗时默认怎么做。

如果你基于像 Koder.ai (koder.ai) 这样的平台构建，它可以帮助你把快速迭代和安全习惯结合起来，尤其是快照与回滚，让“回退到上一个良好状态”成为常规且可练习的操作。

保持闭环短小：一个 SLO、一份笔记、一场短例会。目标不是消灭事故，而是尽早发现、冷静决策并保护用户真正能感觉到的那几件事。