给内部工具的 SLO：简单且可行的可靠性目标

为什么内部工具也需要 SLO（即便只有 20 人使用）

内部工具看起来影响小，是因为受众小。但实际影响往往不小：如果你的运维仪表盘宕机，订单会暂停；如果支持控制台变慢，客户需要等待；如果管理面板出问题，修复积压。

没有明确的可靠性目标时，每次故障都会变成争论。有的人对 10 分钟的短暂故障耸耸肩，另一些人却把它当成危机。你会在嘈杂的聊天、模糊的优先级和最糟糕时刻的突发工作上浪费时间。

SLO 通过设定可以度量的简单期望来解决这个问题。它回答两个实用问题：什么必须正常工作，以及为了让人们完成工作它需要达到什么水平。

“我们会尽量稳定”的隐性成本很快就会显现。工作会在等待工具恢复时停滞。因为没人知道什么是正常，支持请求会成倍增加。工程师被拉去做紧急修复，而不是计划内改进。产品负责人开始不信任系统，转而要求人工备份。小问题会持续存在，因为它们从来没有越过明确的界线。

你不需要完整的可靠性项目。小团队可以从几个以用户为中心的目标开始，例如“登录可用”或“搜索结果加载快速”，再配上一小套与真实操作挂钩的告警。

无论工具如何构建都适用。如果你使用 AppMaster (appmaster.io) 创建内部应用，选择用户依赖的操作，测量可用性与响应时间，只在影响工作时触发告警。

用通俗的话说：SLO、SLI 和 SLA

这三个术语听起来相似，但它们是不同类型的可靠性表达。混淆它们是常见的困惑来源。

一个 SLI（服务级别指标）是一个测量项。它是可以计数的东西，比如“成功请求的百分比”或“页面加载所用时间”。如果你不能可靠地测量它，它就不是一个好的 SLI。

一个 SLO（服务级别目标）是该测量的目标。它回答：对于大多数时间，哪个水平对用户来说足够好？SLO 帮你决定先修什么，什么可以延后。

一个 SLA（服务级别协议）是一个书面的承诺，通常伴随后果。许多内部工具根本不需要 SLA，它们需要的是清晰的目标，而不是法律式的承诺。

举个快速例子：

• SLI（可用性）： 工具可达的分钟百分比。
• SLO（可用性目标）： 每月 99.9% 的可用性。
• SLI（延迟）： 仪表盘的 p95 页面加载时间。
• SLO（延迟目标）： 工作时间内 p95 小于 2 秒。

注意缺失的部分： “从不宕机”或“永远快速”。SLO 不是追求完美。它们让权衡变得可见，以便小团队可以在功能、可靠性工作和避免不必要的劳累之间做出选择。

一个实用规则：如果达成目标需要英雄式的操作，那它不是 SLO，而是空想。先从团队可以平静维护的目标开始，若用户仍然感到痛点再逐步收紧。

选择真正重要的少数用户操作

内部工具的故障通常有具体表现：管理面板能加载但保存记录时一直旋转；运维仪表盘能打开但图表不刷新；员工门户能用但登录在更新后失效。通过关注人们每天依赖的操作（而不是每个页面和按钮），你能获得最大的价值。

先把工具类型写下来，因为它能提示关键路径。管理面板关注“安全地更改某些内容”；运维仪表盘关注“实时看到发生了什么”；门户关注“登录、查找信息并提交请求”。

然后用通俗语言写下顶级用户旅程。一个好的起始集合：

• 登录并进入主界面
• 搜索或筛选并获得结果
• 提交表单（创建/更新）并看到成功提示
• 加载主仪表盘视图并显示最新数据
• 导出或下载用于日常工作的报告

为每个旅程定义什么算失败。要严格且可衡量：500 错误算失败，超时算失败，页面永不完成加载算失败，或者表单返回成功但数据缺失也算失败。

一开始范围要小。选择 1 到 3 个与真实痛点和真实风险匹配的旅程。如果值班页通常是“没人能登录”和“保存按钮卡住”，就从 登录 和 提交表单 开始。等你信任测量和告警后再加上搜索。

选择你能实际测量的 SLI

好的 SLI 很无聊。它们来自你已有的数据，并匹配用户在工具正常或失败时的感受。如果要为了测量它们而搭建一整套新监控，去选更简单的 SLI。

先用用户能理解的可用性开始：我能打开工具并完成任务吗？对于许多内部工具，两个 SLI 就能覆盖大部分痛点：

• 工具的可用性（是否可达并有响应）
• 1 到 3 个关键操作的成功率（登录、搜索、保存、审批）

然后再加延迟，但范围要窄。选择一到两个代表用户抱怨的屏幕或端点，例如加载仪表盘或提交表单。测量所有东西通常会制造噪声和争执。

事先决定测量窗口。对于稳定的工具，常用滚动 30 天；如果你经常发布并想要快速反馈，周度也可行。不管选什么，坚持下去以便趋势有意义。

最后为每个 SLI 确定一个单一的可信来源并写下来：

• 合成检查（机器人访问健康检查或运行简单流程）
• 服务器指标（请求计数、错误、后端延迟）
• 日志（为特定操作统计“成功”与“失败”事件）

例如：如果你的内部应用基于 AppMaster 构建，可以用合成 ping 检测后端可用性，用 API 响应计算成功率，用后端请求时长计算延迟。关键是持续性，而非完美。

设定现实的可用性与延迟 SLO

先选择一个在糟糕的一周也能自圆其说的可用性数字。对于许多内部工具，99.5% 是一个不错的起点。它听起来很高，但留出了正常变更工作的余地。直接跳到 99.9% 往往意味着会有下班后的值班和更慢的发布节奏。

为了让可用性更直观，把它换成时间。一个 30 天的月份大约有 43,200 分钟：

• 99.5% 可用性每月允许约 216 分钟的停机时间
• 99.9% 可用性每月允许约 43 分钟的停机时间

允许的这段停机时间就是你的错误预算。如果你过早耗尽它，就会暂停高风险变更，把精力放在可靠性恢复上。

对于延迟，避免用均值，它会掩盖用户记住的慢时刻。用百分位数（通常是 p95），并把明确的阈值绑定到真实操作。例子：“工作时间内仪表盘 p95 加载 < 2 秒”或“保存操作 p95 < 800 ms”。

设第一个数字的简单方法是观察一周的真实流量，然后选一个比现在稍好但不过分理想的目标。如果 p95 已经是 1.9 秒，设置 2.0 秒的 SLO 是安全且有用的。把目标设成 500 ms 只会制造噪声。

把 SLO 与你的支持能力匹配。小团队应该偏好少量可达成的目标，而不是许多严格的目标。如果没人能在一小时内响应，就别设定假设能在一小时内响应的目标。

让权衡可见：成本、风险与错误预算

更严格的 SLO 听起来令人安心，但它是有代价的。如果把工具从 99.5% 提到 99.9%，你同时也在说“我们接受更少的坏分钟”，这通常意味着更多的值班和更多时间花在可靠性上而不是新功能上。

把这个现实化的最简单方式是用错误预算来讨论。以 99.5% 的月度目标为例，你在 30 天内大约可以“花费” 3.6 小时的故障时间；而 99.9% 只有约 43 分钟。这个差别会改变你停止功能工作去修复问题的频率。

还应把期望与实际使用时间匹配。若工具只在 9am 到 6pm 关键，全天 24/7 的目标成本高昂。你可以为工作时间设更严格的 SLO，而非工作时间放宽，以便团队休息。

计划内维护不应计为失败，前提是它已被通知且有边界。把它作为显式例外（维护窗口）处理，而不是事后忽略告警。

把基本信息写下来让每个人都看到权衡：

• SLO 数值以及未达标时用户会失去什么
• 每月的错误预算（以分钟或小时计）
• 值班规则（谁、何时以及为哪些情况）
• 工作时间与 24/7 的不同期望（如有）
• 什么算作计划内维护

在 4 到 6 周的真实数据后审查目标。如果你从未用掉错误预算，说明 SLO 可能太宽松；如果很快就用光且功能工作停滞，说明可能定得太严格。

将 SLO 映射到团队可维护的告警上

告警不是你的 SLO。告警是“现在有事出错”的信号，用来保护 SLO。一个简单规则：为每个 SLO 创建一个重要的告警，除非能证明额外告警能减少停机，否则要抗拒添加更多。

一个实用方法是基于快速的 SLO 消耗告警（你消耗错误预算的速度）或基于一个清晰阈值的告警，该阈值与用户痛点匹配。如果你的延迟 SLO 是“p95 < 800 ms”，不要对每次慢波动都发页。仅在问题持续存在时才触达值班。

一个保持噪音低的简单划分：

• 紧急页：工具基本不可用，某人需要马上行动。
• 非紧急工单：某项在退化，但可以在工作时间处理。

具体阈值（根据流量调整）：如果可用性 SLO 是每月 99.5%，当可用性在 10 分钟内降到 99% 以下时发页（明确的宕机）。当 6 小时内降到 99.4% 以下时创建工单（慢性消耗）。对于延迟，当 p95 在 15 分钟内高于 1.5 秒发页；当 2 小时内高于 1.0 秒创建工单。

明确所有权。决定谁值班（即便是“本周某个人”），什么算作确认（例如 10 分钟内），以及第一步行动是什么。对于用 AppMaster 运行的内部应用，第一步可能是：检查最近部署、查看 API 错误、然后回滚或重新部署。

每次真实告警后做一项小的后续工作：修复根因或调整告警，使其少触发但仍能捕捉真实用户影响。

导致告警疲劳的常见错误

告警疲劳通常源于良好意图。小团队先加了“几条”告警，然后每周又加一条。很快，人们就不再信任通知，真实故障被忽略。

一个大陷阱是对每个峰值都告警。内部工具常有突发流量（薪资运行、月末报表）。如果告警在 2 分钟的短暂波动时触发，团队会学会忽视它。把告警与用户影响信号关联，而不是原始指标噪声。

另一个陷阱是认为“更多指标=更安全”。更多时常意味着更多页。坚持少量用户真实能感受到的信号：登录失败、页面过慢、关键任务未完成。

最常造成噪声的错误包括：

• 针对症状（CPU、内存）而非用户影响（错误、延迟）发页
• 告警没人负责，以至于从未被调整或移除
• 没有操作手册，每次告警都变成猜测游戏
• 用仪表盘替代告警（仪表盘用于查看，告警用于行动）
• 因系统没有充分指标而随意制造阈值

仪表盘仍然重要，但它们应帮助你在告警后诊断，而不是替代告警。

如果你还没有干净的测量方法，就别假装有。先加基本的埋点（成功率、p95 延迟和“用户是否能完成任务”的检查），然后基于一到两周的真实数据设阈值。

在启用告警前的快速检查清单

在启用告警前做一个短暂的预检。大多数告警疲劳来自跳过这些基本步骤，然后在压力下试图修复。

小团队的实用清单：

• 确认 1 到 3 个关键用户操作（例如：打开仪表盘、保存工单更新、导出报告）。
• 保持在你今天能测量的 2 到 4 个 SLI（可用性/成功率、p95 延迟、关键端点的错误率）。
• 将告警总数限制在 2 到 4 个。
• 同意测量窗口，包括什么算“糟糕”（快速检测用最近 5 分钟，或为减少噪声用最近 30 到 60 分钟）。
• 指定一位负责人（一个人，而不是“团队”）。

接着，确保告警可以被实际处理。一个在没人可用时触发的告警会训练人们忽略它。

在首次发页前决定这些运维细节：

• 值班时间：仅限工作时间，还是全天 24/7
• 升级路径：如果第一联系人未响应，谁是下一个
• 首要操作：确认影响并回滚或缓解的一个或两个步骤
• 简单的月度复查习惯：用 15 分钟查看触发的告警、遗漏的事件，以及 SLO 是否仍与工具使用方式一致

如果你构建或更改了工具（包括在 AppMaster 中），就重新跑一下这个清单。再生成的代码和新流程会改变延迟与错误模式，你的告警也应跟上。

示例：一个小型运维仪表盘的两个 SLO 和三个告警

一个 18 人的运维团队整天使用内部仪表盘查看订单状态、重发失败通知并批准退款。如果它宕机或变慢，工作会迅速停滞。

他们选了两个 SLO：

• 可用性 SLO： 30 天内 99.9% 的页面加载成功（每月约 43 分钟“坏时间”）
• 延迟 SLO： 工作时间内仪表盘 p95 页面加载时间小于 1.5 秒

现在他们添加了三条小团队能处理的告警：

• 硬宕机告警（页面加载失败）： 当成功率在 5 分钟内降到 98% 以下时触发。第一步：检查最近部署、重启 Web 应用、确认数据库健康状况。
• 仪表盘变慢告警： 当 p95 延迟在 10 分钟内超过 2.5 秒时触发。第一步：查找单个慢查询或卡住的后台任务，然后暂时暂停重型报表。
• 错误预算消耗告警： 当预计在接下来的 7 天内会消耗 50% 的月度错误预算时触发。第一步：暂停非必要的变更，直到稳定。

关键在于下一周发生了什么。如果错误预算告警触发了两次，团队需要明确决定：推迟新功能并花两天修复最大的延迟原因（例如未建立索引的表扫描）。如果他们在 AppMaster 上构建工具，可以调整数据模型、再生成并重新部署干净代码，而不是堆叠临时修复。

如何在不把 SLO 变成项目的情况下维持它们

SLO 只有在与真实工作保持连接时才有用。窍门是把它当成小习惯，而不是新项目。

用适合小团队的节奏并把它附加到已有会议上。每周快速看一眼就能捕捉漂移，每月调整一次在有真实数据后足够了。

一个轻量流程能够维持下去：

• 每周（10 分钟）：查看 SLO 图表和最近几次告警，确认没有悄然变坏。
• 每次事故后（15 分钟）：标记原因并记录受影响的用户操作（登录、搜索、保存、导出）。
• 每月（30 分钟）：复盘最常见的事故模式，并为下个月选一个修复项。
• 每月（10 分钟）：移除或调整一条嘈杂的告警。

把改进保持小而可见。如果“每周一早上页面变慢”出现三次，就做一项具体改动（缓存一个报表、加一个索引、把重负载任务安排到别的时间），然后下周观察 SLI。

用 SLO 去委婉而明确地说“否”。当收到一个低价值功能需求时，指出当前的错误预算并问：“这个改动会不会风险到我们的保存或审批流程？”如果你已经在消耗预算，优先保证可靠性。这不是阻挡，而是优先级管理。

保持文档简洁：每个工具一页。包含关键用户操作、SLO 数值、与之关联的少量告警和负责人。如果工具基于 AppMaster，补充在哪里查看日志/指标以及谁可以部署变更，然后停止写文档。

接下来的步骤：从小开始，然后逐个工具改进

把可靠性变成真实最简单的方式是把首次设置压得很小。挑一个当它出问题时会造成真实痛点的内部工具（值班交接、订单审批、退款、库存修改），并围绕人们每天做的少数操作设定目标。

一个大多数团队可以复制的最小可行设置：

• 选 1 个工具和 2 个关键用户操作（例如：打开仪表盘和提交审批）。
• 定义 2 个你现在能测量的 SLI：端点/页面的可用性，以及该操作的 p95 延迟。
• 设定 2 个简单的 SLO（示例：每月 99.5% 可用性，工作时间内 p95 < 800 ms）。
• 创建 2 到 3 条告警：一条硬宕机、一条持续性延迟、一条快速错误预算消耗告警。
• 每周复查 10 分钟：告警是有帮助，还是只是制造噪声？

一旦稳定，慢慢扩展：每月增加一个操作或一个工具。如果你无法说出谁会负责某条告警，就别着急创建它。

如果你在构建或重建内部工具，AppMaster 可以让维护工作更易持续。你可以以可视化方式更新数据模型和业务逻辑，重新生成干净代码，随着需求变化保持 SLO 与工具当前行为的一致性。

尝试从第 1 天就为一个内部工具添加基本 SLO。你会得到更清晰的期望，更少的意外，以及小团队能跟得上的告警。