4. 可用性SLI口径:服务可用性定义、Uptime计算口径、健康检查探针设计
可用性(Availability)是SRE承诺中最核心的SLI之一,但“服务是否可用”在不同架构、不同探针策略下会得出截然不同的数值。本章从服务可用性定义出发,建立Uptime计算口径,并给出健康检查探针设计的工程化方法,确保IaC中声明的可用性SLI口径可观测、可复现、可审计。
4.1 服务可用性定义:从二进制到滑动窗口
传统“服务是否运行”的二进制判断(0或1)在分布式系统中过于粗糙。现代SRE采用时间窗口内成功请求占比或探针连续成功占比来定义可用性。
| 定义模型 | 口径公式 | 适用场景 | IaC声明方式 |
|---|---|---|---|
| 二进制Uptime | Uptime = 运行时间 / 总时间 | 单机、VM、物理机 | terraform resource status check |
| 请求成功率 | Availability = 成功请求数 / 总请求数 | API、微服务、网关 | prometheus http_requests_total |
| 探针连续成功 | Availability = 连续成功窗口 / 总窗口数 | 负载均衡、健康检查 | kubernetes probe + SLI exporter |
| 滑动窗口可用性 | Availability = 1 - (故障时间 / 滑动窗口时长) | SLO精细化、多AZ | sloth / pyrra SLI rules |
口径选择原则:在IaC中,优先使用探针连续成功作为基础设施层SLI,使用请求成功率作为应用层SLI。两者在SLO中应分别声明,不可混用。
4.2 Uptime计算口径:探针视角 vs 用户视角
Uptime计算口径存在两个核心视角,直接影响SLI数值和SLO达标判断。
- 探针视角(Probe Uptime):以健康检查探针的连续成功/失败为判断依据。探针每N秒执行一次,连续M次失败即判定为故障开始,连续K次成功即判定为恢复。故障时长 = 故障开始时间戳 - 恢复时间戳。
- 用户视角(User Uptime):以用户请求的成功/失败为判断依据。使用滑动窗口(如28天)内成功请求占比计算可用性。故障时长 = 用户请求失败持续时长。
两种视角在IaC中的计算口径差异如下:
| 维度 | 探针视角 | 用户视角 |
|---|---|---|
| 数据源 | 健康检查探针日志 | 负载均衡/API网关访问日志 |
| 故障判定粒度 | 探针周期(通常5s-30s) | 用户请求粒度(ms级) |
| 故障时长计算 | 探针连续失败时间戳差 | 请求失败时间窗口聚合 |
| IaC声明方式 | probe.failureThreshold * probe.periodSeconds | sloth SLI: (success / total) * 100 |
| 典型偏差 | 可能漏检瞬时故障 | 可能受流量波动影响 |
口径偏差警告:探针视角的Uptime通常比用户视角高1%-3%。在IaC中声明SLO时,必须明确标注使用哪种口径,否则SLO达标判定将产生争议。建议在
slo.yaml中增加uptime_perspective: probe | user字段。
4.3 健康检查探针设计:三层探针体系
健康检查探针是Uptime计算的底层数据来源。设计不当会导致“假阳性”(误报故障)或“假阴性”(漏报故障)。推荐在IaC中声明三层探针体系:
- L1 存活探针(Liveness Probe):检测进程是否存活。失败时重启容器/进程。周期短(5-10s),阈值低(1-3次)。
- L2 就绪探针(Readiness Probe):检测服务是否可接收流量。失败时从负载均衡摘除。周期中等(10-15s),阈值适中(3-5次)。
- L3 深度探针(Deep Probe):检测业务逻辑是否正常(如数据库连接、缓存、下游依赖)。失败时触发告警但不重启。周期较长(30-60s),阈值较高(5-10次)。
4.4 探针参数在IaC中的声明规范
以Kubernetes为例,在IaC中声明健康检查探针时,必须显式设置以下参数,确保Uptime计算口径一致:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-service
spec:
template:
spec:
containers:
- name: app
image: my-service:1.0.0
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 15
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 3
# 深度探针通过自定义Exporter实现
IaC口径一致性检查清单:
periodSeconds×failureThreshold= 探针判定故障的最短时间periodSeconds×successThreshold= 探针判定恢复的最短时间- 故障时长 = 恢复时间戳 - 故障开始时间戳(探针粒度)
- Uptime = 1 - (故障时长总和 / 总观测时长)
4.5 可用性SLI口径的IaC模板
以下是一个完整的Prometheus SLI规则声明,用于计算探针视角的可用性:
# sloth SLI规则: probe-based availability
apiVersion: sloth.slok.dev/v1
kind: PrometheusServiceLevel
metadata:
name: my-service-availability
namespace: monitoring
spec:
service: my-service
labels:
owner: sre-team
sli_type: availability
uptime_perspective: probe
slos:
- name: probe-availability-99-9
objective: 99.9
description: "探针视角可用性SLO 99.9%"
sli:
events:
error_query: |
sum(
rate(
probe_success_total{job="my-service", result="failure"}[5m]
)
)
total_query: |
sum(
rate(
probe_success_total{job="my-service"}[5m]
)
)
alerting:
name: MyServiceProbeAvailability
labels:
severity: critical
annotations:
summary: "探针可用性低于SLO"
口径审计建议:在IaC仓库中为每个服务维护一个
sli-spec.yaml文件,明确记录uptime_perspective、probe_period、failure_threshold、recovery_threshold四个字段。CI/CD流水线在部署前自动校验口径一致性,防止探针参数变更导致SLI口径漂移。
4.6 常见口径陷阱与规避策略
| 陷阱 | 现象 | 根因 | IaC规避策略 |
|---|---|---|---|
| 探针周期过长 | Uptime虚高,漏检短时故障 | periodSeconds > 30s | 强制periodSeconds ≤ 15s |
| 阈值设置不对称 | 故障恢复慢于故障发现 | failureThreshold ≠ successThreshold | 声明对称阈值模板 |
| 探针路径与用户路径不一致 | 探针显示正常,用户请求失败 | /healthz 未覆盖业务逻辑 | L3深度探针覆盖核心依赖 |
| 忽略启动初始化时间 | 服务启动期间误报故障 | initialDelaySeconds 未设置 | 强制initialDelaySeconds ≥ 启动时间 |
| 多AZ探针未聚合 | 单AZ故障被全局Uptime稀释 | 全局聚合而非分AZ聚合 | 按AZ维度声明独立SLI |
通过以上口径定义、计算方法和探针设计,可以在IaC中建立一套可审计、可复现、可自动化的可用性SLI体系,为后续SLO声明和错误预算管理奠定坚实基础。