4. SLI口径设计原则：粒度、覆盖范围与稳定性
SLI（Service Level Indicator）口径设计是质量门禁的基石。口径定义不当，门禁要么形同虚设，要么频繁误报。本节从三个核心维度——粒度、覆盖范围、稳定性——展开，确保每个SLI都能真实反映服务质量，并能在门禁流水线中稳定执行。
4.1 口径的粒度：从粗到细的分层设计
粒度决定了SLI能感知到的最小异常单元。粒度过粗会掩盖局部故障，粒度过细则带来巨大的存储与计算开销。推荐采用分层粒度策略：
| 粒度层级 | 典型维度 | 适用场景 | 风险 |
|---|---|---|---|
| 全局粒度 | 全集群、全服务 | 整体健康度大盘、高管报告 | 掩盖单机房故障 |
| 服务粒度 | 单个微服务、API组 | 服务级SLO、门禁准入 | 无法定位具体接口 |
| 接口粒度 | 单个URI、gRPC方法 | 精细化排障、容量规划 | 指标爆炸 |
| 实例粒度 | Pod、VM实例 | 故障隔离、热点排查 | 存储成本高 |
实践建议：门禁场景优先使用服务粒度+关键接口粒度。例如：核心下单接口使用接口粒度SLI，非核心通知服务使用服务粒度SLI。避免全量接口都使用实例粒度，否则门禁计算延迟会显著增加。
4.2 口径的覆盖范围：避免盲区与过度覆盖
覆盖范围定义了SLI的“观测边界”。常见的覆盖范围问题包括：
- 覆盖不足：只统计了成功请求，忽略了超时、熔断、限流等失败场景。
- 过度覆盖：将健康检查、内部心跳、重试流量计入SLI，导致指标虚高或虚低。
- 范围漂移：随着版本迭代，新接口未被纳入，旧接口已下线但仍在统计。
设计覆盖范围时，应遵循“显式声明+自动校验”原则：
- 明确包含：所有用户可见的、业务关键路径的请求。
- 明确排除：健康检查、内部探活、自动化测试流量、重试请求（仅统计首次）。
- 定期审计：通过服务拓扑自动比对SLI覆盖的接口列表与实际运行接口列表。
常见陷阱：很多团队将“所有HTTP 200”视为成功，但忽略了业务逻辑错误（如“余额不足”返回200但实际失败）。覆盖范围必须区分传输层成功与业务层成功。
4.3 口径的稳定性要求：可重复、可对比、可演进
稳定性是SLI口径在门禁中长期运行的保障。不稳定的口径会导致门禁频繁抖动，失去信任。稳定性包含三个子要求：
| 要求 | 定义 | 反例 | 正例 |
|---|---|---|---|
| 可重复性 | 相同输入数据，多次计算得到相同结果 | 依赖随机采样、非幂等聚合函数 | 使用固定窗口、幂等计数 |
| 可对比性 | 不同时间窗口、不同版本间的口径定义一致 | 本周SLI排除重试，下周又包含重试 | 口径变更走版本化配置 |
| 可演进性 | 口径能平滑升级，不破坏历史数据对比 | 直接修改现有SLI定义 | 新增v2口径，保留v1口径并行运行 |
4.4 口径设计原则综合决策流程
以下SVG展示了从需求到口径落地的完整决策流程，帮助SRE在门禁场景中快速确定SLI口径：
4.5 口径设计检查清单
在实际落地中，建议使用以下清单逐项确认SLI口径质量：
- 粒度检查：是否至少覆盖到服务粒度？关键接口是否有独立口径？
- 覆盖检查：是否显式排除了健康检查与重试？是否区分了传输成功与业务成功？
- 稳定性检查：口径定义是否版本化管理？是否保留了历史口径用于对比？
- 成本检查：接口粒度的SLI数量是否超过服务总数的5倍？实例粒度的SLI是否仅用于排障而非门禁？
核心结论：好的SLI口径 = 合适的粒度（不粗不细） + 清晰的覆盖范围（不遗漏不污染） + 稳定的定义（不变形不漂移）。三者缺一不可，共同构成质量门禁的可信基础。