19.10.1 运维度量指标体系与口径定义

运维度量指标体系的目标是统一口径、可追溯、可比较，支撑SLA评估、成本治理与效能提升。指标围绕业务与技术双维度构建，并覆盖资源、服务、流程与人员四类对象，确保从基础设施到交付链路形成闭环。

原理草图（指标采集与计算链路）：

指标分层建议采用“结果指标—过程指标—资源指标”结构：结果指标衡量业务影响，如可用性与故障影响面；过程指标衡量运维活动质量，如变更成功率与修复时长；资源指标衡量投入与利用，如CPU利用率与成本占比。每个指标需明确口径、采集源、计算公式、统计周期与责任人。

常用指标体系与口径定义示例：
- 可用性（Availability）：统计周期内服务可用时间占比
公式：=（总时长-不可用时长）/总时长
口径：不可用时长需定义触发条件与合并规则（如连续告警合并、计划内维护是否计入）。
- 故障频次与影响面：故障次数按工单/事件编号计数；影响面按受影响用户数、QPS损失或交易额损失，需统一估算规则。
- MTTR：从故障确认开始到服务恢复结束的平均时长，需明确“确认”“恢复”的事件边界。
- MTBF：=统计周期总时长/故障次数，用于衡量稳定性趋势。
- 变更成功率：成功变更次数/总变更次数，失败定义需含回滚、紧急修复或影响SLA的变更。
- Lead Time for Change：从需求冻结/变更申请到生产发布的耗时，需区分标准变更与紧急变更。
- 告警噪声率：无效告警数/告警总数，需定义无效告警判定标准。
- 资源利用率：CPU/内存/磁盘/网络利用率按加权平均或P95统计，明确采样频率与排除异常点规则。
- 成本效率指标：单位QPS成本、单位交易成本，成本来源需明确包含的资源与分摊策略。
- 交付稳定性：发布后一定窗口内的故障率或回滚率，需定义窗口长度。

安装与采集示例（以 Prometheus 为例）：

# 安装 Prometheus（示例为二进制安装）
useradd -r -s /sbin/nologin prometheus
tar -xzf prometheus-2.47.0.linux-amd64.tar.gz -C /opt/
ln -s /opt/prometheus-2.47.0.linux-amd64 /opt/prometheus
cat >/etc/systemd/system/prometheus.service <<'EOF'
[Unit]
Description=Prometheus
After=network.target
[Service]
User=prometheus
ExecStart=/opt/prometheus/prometheus \
  --config.file=/opt/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/prometheus/data
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload && systemctl enable --now prometheus
systemctl status prometheus --no-pager

Prometheus 配置示例（采集节点资源与Nginx状态）：

# /opt/prometheus/prometheus.yml
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.0.11:9100','10.0.0.12:9100']
  - job_name: 'nginx'
    metrics_path: /metrics
    static_configs:
      - targets: ['10.0.0.21:9113']

指标计算示例（PromQL 口径计算）：

# 可用性（近30天，1-错误率）
1 - (sum(rate(http_requests_total{status=~"5.."}[5m])) 
     / sum(rate(http_requests_total[5m])))

# CPU利用率P95（1小时窗口）
quantile_over_time(0.95, 1 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m]))[1h:])

# 告警噪声率（需对有效/无效标签打标）
sum(increase(alerts_total{valid="false"}[7d])) 
/ sum(increase(alerts_total[7d]))

指标计算示例（SQL 口径计算，事件工单表）：

-- MTTR（单位分钟）
SELECT 
  ROUND(AVG(TIMESTAMPDIFF(MINUTE, confirm_time, recover_time)),2) AS mttr_min
FROM incident_ticket
WHERE status='closed'
  AND confirm_time BETWEEN '2024-01-01' AND '2024-01-31';

-- 变更成功率
SELECT 
  ROUND(SUM(CASE WHEN result='success' THEN 1 ELSE 0 END)/COUNT(*),4) AS change_success_rate
FROM change_record
WHERE create_time BETWEEN '2024-01-01' AND '2024-01-31';

指标字典样例（可维护在CMDB或配置库中）：

# /etc/ops-metrics/metrics-dict.yaml
- name: availability
  definition: "统计周期内服务可用时间占比"
  formula: "(total_time - downtime)/total_time"
  source: "prometheus:http_requests_total"
  owner: "sre-team"
  period: "monthly"
  change_log: "2024-01-15 init"
- name: mttr
  definition: "故障确认到恢复的平均时间"
  formula: "avg(recover_time - confirm_time)"
  source: "incident_ticket"
  owner: "ops-team"
  period: "monthly"
  change_log: "2024-01-20 add boundary"

口径定义原则与实施要点：
1. 统一事件边界：故障、变更、发布、告警、维护等事件需有统一起止定义与记录标准。
2. 统计周期一致：按日、周、月或季度统计需固定周期，并规定跨周期的归属规则。
3. 数据来源可追溯：指标数据来自监控、日志、工单、CMDB与CI/CD系统，避免人工填报为唯一来源。
4. 去重与合并规则明确：同一故障的多次告警或多个工单需合并，避免重复计数。
5. 指标分层与权重：对关键系统与非关键系统设置权重，避免平均值掩盖风险。
6. 指标可行动：每项指标必须关联改进动作与责任主体。

排错与校验示例：

# 排查Prometheus抓取失败
curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, health: .health, lastError: .lastError}'

# 验证Nginx指标端口是否可达
curl -s http://10.0.0.21:9113/metrics | head -n 5

# 检查指标口径是否出现负值/异常
mysql -h db -u ops -p -e "
SELECT * FROM metrics_daily 
WHERE (availability < 0 OR availability > 1) 
   OR mttr_min < 0
LIMIT 20;
"

练习：
1. 基于现有工单表设计 MTTR 与故障频次统计SQL，并输出按业务线分组的月报。
2. 以“变更成功率”为例，编写指标字典条目并补充口径说明（含失败判定规则）。
3. 在 Prometheus 中计算某服务 P95 响应时间与可用性，并在看板中验证数据是否与日志统计一致。