19.12.8 流程度量与持续改进方法

流程度量与持续改进方法#

流程度量的目标是让运维流程从“可执行”走向“可量化、可优化”。本节以变更流程为例，给出指标设计、数据采集、可视化、排错与演练的完整闭环。

1. 原理草图：流程数据闭环#

2. 指标体系与口径示例#

效率类：Lead Time（需求创建到发布完成），变更实施时长，MTTR。
质量类：变更成功率=成功变更数/总变更数，回滚率。
稳定性类：事件频次、告警噪声比=无效告警/总告警。
合规类：变更审批合规率=合规变更/总变更。
成本类：单位交付成本=总工时/发布次数。

口径示例（必须固定）
- Lead Time 起点：工单“创建时间”；终点：发布“结束时间”。
- 变更成功：发布状态=success 且无 24h 内回滚。

3. 数据采集与指标落地（含安装与命令）#

3.1 指标存储选型：Prometheus + Pushgateway#

适用于“流程类指标”（非时序业务指标）统一拉取或推送。

安装（Ubuntu/Debian）

# 安装 Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.49.0/prometheus-2.49.0.linux-amd64.tar.gz
tar -zxvf prometheus-2.49.0.linux-amd64.tar.gz
sudo mv prometheus-2.49.0.linux-amd64 /opt/prometheus

# 安装 Pushgateway
wget https://github.com/prometheus/pushgateway/releases/download/v1.6.2/pushgateway-1.6.2.linux-amd64.tar.gz
tar -zxvf pushgateway-1.6.2.linux-amd64.tar.gz
sudo mv pushgateway-1.6.2.linux-amd64 /opt/pushgateway

启动

# 启动 Prometheus
/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/prometheus/data

# 启动 Pushgateway
/opt/pushgateway/pushgateway

prometheus.yml 示例

global:
  scrape_interval: 30s
scrape_configs:
  - job_name: 'pushgateway'
    static_configs:
      - targets: ['127.0.0.1:9091']

3.2 变更流程指标采集脚本示例#

假设变更系统提供 API，抽取变更成功率与 Lead Time。

#!/usr/bin/env bash
# 文件路径：/opt/ops/metrics/change_metrics.sh
# 依赖：curl、jq

API="https://change.example.com/api/v1/changes?from=2024-01-01&to=2024-01-31"
DATA=$(curl -s "$API")

TOTAL=$(echo "$DATA" | jq '.changes | length')
SUCCESS=$(echo "$DATA" | jq '[.changes[] | select(.status=="success")] | length')

# 计算平均 Lead Time（小时）
LEAD_SUM=$(echo "$DATA" | jq '[.changes[] | (.finish_ts - .create_ts)/3600] | add')
LEAD_AVG=$(echo "scale=2; $LEAD_SUM / $TOTAL" | bc)

cat <<EOF | curl --data-binary @- http://127.0.0.1:9091/metrics/job/change_metrics
change_total $TOTAL
change_success $SUCCESS
change_success_rate $(echo "scale=4; $SUCCESS / $TOTAL" | bc)
change_lead_time_avg_hours $LEAD_AVG
EOF

关键命令解释
- jq '.changes | length'：统计变更数量。
- (.finish_ts - .create_ts)/3600：计算单次变更耗时小时数。
- pushgateway 接收后，Prometheus 会定期抓取。

4. 可视化指标查询示例（PromQL）#

# 变更成功率
change_success_rate

# 平均 Lead Time（小时）
change_lead_time_avg_hours

# 失败变更数
change_total - change_success

5. 流程健康度评估示例#

瓶颈分析：将“审批耗时、实施耗时、回滚耗时”拆分并对比。

# 示例：从审计日志中统计审批耗时（单位秒）
cat /var/log/change_audit.log | awk -F',' '{sum+=$5; count++} END {print sum/count}'

稳定性趋势：统计重复故障率。

# 从问题库中统计重复故障占比（示例 CSV）
awk -F',' 'NR>1{total++; if($4=="repeat") repeat++} END{print repeat/total}' problems.csv

6. 排错与常见问题#

Prometheus 抓取不到 Pushgateway

# 检查端口监听
ss -lntp | grep 9091

# 手动访问
curl -s http://127.0.0.1:9091/metrics | head

若无输出：检查 Pushgateway 是否启动、是否被防火墙阻挡。

指标值始终为 0

# 检查 API 返回结构
curl -s "$API" | jq '.changes[0]'

若字段名不一致：修正 jq 路径或 API 参数。

Prometheus 无数据

# Prometheus target 状态
curl -s http://127.0.0.1:9090/api/v1/targets | jq '.data.activeTargets[] | {job: .labels.job, health: .health}'

health != "up"：检查 scrape 配置与网络。

7. 持续改进方法落地示例（PDCA）#

Plan：设定“变更成功率 ≥ 98%”
Do：引入自动化回滚与发布前检查
Check：月度对比 change_success_rate
Act：将失败变更 Top3 根因纳入流程改造

RCA 模板示例（Markdown）

# RCA 报告
- 事件编号：INC-202401-012
- 影响范围：支付服务
- 根因：发布前未校验配置差异
- 行动项：
  1. 增加配置差异检查脚本
  2. 灰度发布门禁：失败率>2%自动回滚

8. 练习与实战#

练习一：接入一个“变更系统 API”，实现成功率与平均 Lead Time 上报。
练习二：在 Grafana 中创建“变更流程看板”，含成功率、失败数、Lead Time。
练习三：模拟一次失败发布，填写 RCA 报告，并制定 3 条改进行动。