HelloWorld SLI 定义教程

为 HelloWorld 服务定义 SLI 的核心是把“用户真正感受到的好坏”量化：挑出一到三个最关键的体验指标（比如可用性、成功率与响应时延），为它们设定清晰的测量方法、统计窗口和合格阈值，并保证埋点与聚合逻辑稳定可靠，这样得到的 SLI 才能真实反映用户体验并用于后续 SLO/SLA 决策。

先弄清几个概念（像给朋友解释那样）

SLI、SLO、SLA 这三兄弟常常被混在一起。我喜欢把它们比作“温度计、目标体温和承诺”。

• SLI（Service Level Indicator）：温度计——用来量化某个具体的用户体验维度，比如“请求成功率”或“平均响应时延”。
• SLO（Service Level Objective）：目标体温——告诉我们希望温度计显示什么范围，例如“95% 请求响应时间小于200ms”。
• SLA（Service Level Agreement）：对外承诺和处罚条款——如果长时间超出 SLO，可能会触发赔偿或合同条款。

为什么要为 HelloWorld 这样简单的服务也定义 SLI？

很多人觉得 HelloWorld 太简单，不需要监控。但正因为简单，它是衡量整条链路基础能力的好窗口：如果连最简单的请求都出问题，说明基础设施或网络链路有根本性问题。SLI 帮助我们把这种问题量化、自动化检测并采取行动。

一步步定义 HelloWorld 的 SLI（费曼式分解）

我会把整个过程拆成小步骤，像教小朋友一样讲清楚每一步“为什么要做”和“怎么做”。

步骤 1：明确用户关心的“体验”是什么

• 问自己两句话：用户来打这个接口是为了什么？他们最不希望看到什么结果？
• 对于 HelloWorld，常见的用户感知维度是：服务是否可达（可用性）、请求是否成功（成功率）、响应是否快速（延迟）。

步骤 2：把体验转化为可测量的指标（候选 SLI）

把“可用”或“快”变成数学式：可以做的候选有

• 可用性（Availability）：在给定窗口内，返回非 5xx 的请求占比。
• 成功率（Success Rate）：返回 2xx 的请求占比，或业务层面“有效”的响应占比。
• 延迟分位（Latency P50/P95/P99）：响应时间的第 50、95、99 百分位。
• 错误率（Error Rate）：返回 4xx/5xx 或特定错误码的占比。

步骤 3：选最关键的一到三个 SLI

别贪心，越简单越好。HelloWorld 推荐的组合是：

• 主要 SLI：可用性（如 99.9% 可用）
• 次要 SLI：响应时延 P95（比如小于 200ms）
• 辅助 SLI（可选）：错误率（如 <0.1%）

原因很直白：可用性直接反映用户能否成功拿到回复；P95 能反映大多数用户的体验；错误率则指示功能性失败。

步骤 4：定义清晰的测量方法（最关键）

很多团队在这一步就出错了：指标定义模糊导致数据不可比、告警噪音大。写清楚三个要素：

• 事件选择：哪些请求被计入分子/分母，例如是否包含内部健康探测、是否排除缓存命中等。
• 时间窗口：SLI 是按 1 分钟、5 分钟、1 小时还是 28 天计算？不同用途选择不同窗口。
• 聚合逻辑：先对每实例计算再平均，还是全局合并计数再计算比率？要避免跨实例偏差。

常见 SLI 定义示例（带具体公式）

如何选统计窗口与阈值（直观且实用）

想像温度计的读数：太短窗口会被瞬时抖动干扰，太长窗口会掩盖短期故障。常见建议：

• 短窗口（1~5 分钟）：用于实时告警，快速响应，但容易抖动。
• 中窗口（1 小时）：用于日常观察，平衡波动与可解释性。
• 长窗口（28 天）：用于 SLO 合规性评估与外部承诺。

阈值设定也要结合业务：对 HelloWorld 这类 API，P95 200ms、可用性 99.9% 是常见初始值；但最重要的是与产品、运营沟通再微调。

埋点与数据采集要点（别把测量搞坏了）

一个坏的埋点会让再多的策略都白费。我会强调几个实务要点：

• 统一事件格式：请求 id、timestamp、status_code、response_time_ms、user_origin 等字段必须标准化。
• 排除探针流量：健康检查、内网探测要在采集层被标记并排除。
• 样本策略：低成本下可采样请求，但在计算 SLI 时要保证样本能代表总体，或者采用计数汇总方式。
• 聚合位置：边缘（负载均衡）、应用或代理层各有利弊，选择对你最可靠且可追溯的层。

从数据到告警与 SLO（把数据用起来）

SLI 单独看没意义，和 SLO/告警结合才能驱动行动。实践建议：

• 把 SLO 划分为“警戒线”（burn rate）和“容忍线”。当短期违反速率高时触发运维响应。
• 设置多级告警：短窗口高灵敏度用于运维快速介入；长窗口用于通知产品/管理层。
• 用 burn-rate 模型评估剩余可靠性预算，避免临近 SLO 末期才慌张。

具体计算示例（想象一下实际数据）

举个最简单的比例计算例子：

• 统计窗口：过去 1 小时
• 总请求数：36000（约 10 rps）
• 5xx 错误数：36
• 可用性 = 1 – (36 / 36000) = 0.999 = 99.9%

这说明在过去一小时内可用性满足 99.9%。如果一周内某些短时故障导致某天可用性降到 99.7%，需要看是短时突发还是持续性问题。

常见陷阱（别中招）

• 模糊分子/分母：比如把重试请求计入分母但重复计数，会让错误率看起来更低。
• 忽略冷启动/部署影响：新版本发布时短时间内延迟上升，应该在 SLI 计算或告警规则里考虑灰度窗口。
• 把监控埋点放在容易失败的位置：例如仅采集应用层日志但不收集网关层数据，会丢掉路由异常的视角。

验证与演练（把纸上方案变成可靠的实践）

定义完别就放着，实践中要验证：

• 把 SLI 的计算结果和真实用户投诉做对照，看是否匹配感知。
• 进行故障演练（chaos testing），验证告警能否及时触达并触发流程。
• 定期评审 SLI 与 SLO，尤其在流量模式或架构变化后。

一点小技巧（实战派）

• 把 SLI 指标写成“可执行的测试用例”，例如每天自动回放 100 次 HelloWorld 请求，记录成功率与延迟。
• 对高延迟请求采样完整的堆栈/trace，帮助排查。
• 用简单的仪表板展示短期与长期 SLI，避免不同窗口的“数字矛盾”。

结尾随想（不那么正式的提醒）

定义 SLI 有点像在做基础设施的“用户焦虑笔记”：记录哪些表现会让用户焦虑、并把这些焦虑量化。HelloWorld 看似简单，但把它做对了能带来规范化的监控习惯，后续把同一套方法推广到更复杂服务就轻松多了。说到底，别把 SLI 当成一次性的文档，把它当成会说话的指示器，持续喂入真实数据并据此调整策略，效果会越用越好。