19.10.2 SLA设计、分级与评估方法

SLA（服务等级协议）用于约定服务可用性、性能与支持响应承诺，是业务与运维的共同语言。设计需与业务重要性、用户体验和风险承受度匹配，同时具备可衡量、可执行、可追溯的特性。

SLA设计核心要素包括：服务对象与边界、可用性目标、性能目标、故障恢复目标、支持响应窗口、例外条款与维护窗口。建议以“监控数据+变更审计+事件管理”为度量基础。

SLA原理草图（数据流与评估闭环）：

常见指标与口径示例（可执行）：
- 可用性（Availability）：按时间维度衡量服务可达性，明确统计口径（剔除维护、变更、不可抗力等）。
- 性能（Latency/Throughput）：关键接口响应时间与吞吐能力，定义统计周期与百分位口径（P95/P99）。
- 可靠性（Error Rate）：错误率、失败率、超时率等，需与告警策略一致。
- 恢复能力（RTO/RPO）：故障恢复时间目标与数据恢复点目标。
- 支持响应（MTTA/MTTR）：告警响应时间、故障修复时间目标。

Prometheus 指标口径与计算示例（可直接运行）：

# 1) 计算30天可用性（成功率=1-5xx比例）
# 以Nginx为例，状态码指标为 nginx_http_requests_total
# 预期效果：输出可用性百分比
curl -s http://prometheus:9090/api/v1/query \
  --data-urlencode 'query=(1 - (sum(rate(nginx_http_requests_total{status=~"5.."}[30d])) / sum(rate(nginx_http_requests_total[30d])))) * 100'

# 2) 计算接口P99延迟（以HTTP请求耗时直方图为例）
# 预期效果：输出P99耗时（秒）
curl -s http://prometheus:9090/api/v1/query \
  --data-urlencode 'query=histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))'

# 3) 计算MTTR（需结合事件系统导出）
# 假设事件系统导出修复耗时到MTTR指标
curl -s http://prometheus:9090/api/v1/query \
  --data-urlencode 'query=avg(mttr_minutes[30d])'

SLA分级模型（示例）：
- P0/核心业务：可用性 ≥ 99.99%，RTO ≤ 30分钟，RPO ≤ 5分钟，7x24支持。
- P1/关键业务：可用性 ≥ 99.9%，RTO ≤ 1小时，RPO ≤ 15分钟，7x24支持。
- P2/重要业务：可用性 ≥ 99.5%，RTO ≤ 4小时，RPO ≤ 1小时，工作时段支持。
- P3/一般业务：可用性 ≥ 99%，RTO ≤ 8小时，RPO ≤ 24小时。

SLA评估步骤（含示例流程）：
1. 口径统一：定义统计范围、时间窗口、剔除项与采集来源。
2. 指标采集：监控+日志+事件系统，保证可追溯。
3. 事件归因：区分系统故障、变更事故、外部依赖与用户误操作。
4. 评分评估：按权重综合可用性、性能与响应指标。
5. 例外管理：维护窗口、灾害事件、供应商故障纳入审计。
6. 持续改进：未达标项进入问题管理与技术债治理。

SLA统计报表示例（Prometheus + 规则配置）：

# /etc/prometheus/rules/sla.rules.yml
groups:
- name: sla.rules
  rules:
  - record: sla:availability_30d
    expr: (1 - (sum(rate(nginx_http_requests_total{status=~"5.."}[30d])) / sum(rate(nginx_http_requests_total[30d])))) * 100
  - record: sla:latency_p99_5m
    expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
  - record: sla:error_rate_5m
    expr: sum(rate(nginx_http_requests_total{status=~"5.."}[5m])) / sum(rate(nginx_http_requests_total[5m]))

评估汇总脚本示例（将指标导出为SLA报表）：

#!/usr/bin/env bash
# file: /usr/local/bin/sla_report.sh
# 作用：拉取Prometheus指标并输出到CSV
PROM_URL="http://prometheus:9090/api/v1/query"

query() {
  curl -s "${PROM_URL}" --data-urlencode "query=$1" | jq -r '.data.result[0].value[1]'
}

AVAIL=$(query 'sla:availability_30d')
P99=$(query 'sla:latency_p99_5m')
ERR=$(query 'sla:error_rate_5m')

echo "metric,value" > /var/reports/sla_report.csv
echo "availability_30d,${AVAIL}" >> /var/reports/sla_report.csv
echo "latency_p99_5m,${P99}" >> /var/reports/sla_report.csv
echo "error_rate_5m,${ERR}" >> /var/reports/sla_report.csv

echo "SLA report generated: /var/reports/sla_report.csv"

故障排查要点（示例）：
- 指标缺失：检查采集端是否注册到Prometheus。

# 预期效果：能看到目标为UP
curl -s http://prometheus:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, health: .health}'

可用性异常偏低：检查5xx是否由上游依赖导致。

# 预期效果：确认上游5xx占比
curl -s http://prometheus:9090/api/v1/query \
  --data-urlencode 'query=sum(rate(nginx_http_requests_total{status=~"5..", upstream!="-" }[5m]))'

P99异常升高：定位高延迟路径与资源瓶颈。

# 预期效果：查出慢接口路径
curl -s http://prometheus:9090/api/v1/query \
  --data-urlencode 'query=topk(5, histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, path)))'

练习（建议落地）：
1. 以一个Web服务为对象，定义P1级SLA，并给出可用性与P99口径。
2. 在Prometheus中写出可用性与P99的录制规则，生成30天SLA报表。
3. 模拟一次维护窗口，将时间段从统计口径中剔除，并重新计算SLA。
4. 设计一份SLA评估模板（包含权重与评分），并对过去7天数据出分。

注意事项：
- 避免“过度承诺”和“不可量化承诺”，以历史数据与容量规划为基础。
- SLA评估结果与绩效、资源投入、成本治理挂钩，确保标准可执行、成本可控、体验可持续。