3. 变更失败率的数据采集：数据源选择、清洗与标准化、采集频率与精度
变更失败率（Change Failure Rate, CFR）的准确性高度依赖数据采集的质量。原始数据分散在CI/CD工具、监控系统和事件管理平台中，必须经过系统化的选择、清洗与标准化，才能形成可靠的SLI口径。本节从数据源选型、清洗规则、采集频率三个维度展开。
3.1 数据源选择：三类核心系统
CFR的计算需要“变更事件”与“失败事件”的关联。单一数据源无法覆盖全场景，必须从以下三类系统中提取互补数据：
| 数据源类型 | 典型工具 | 提供的关键字段 | 在CFR中的角色 |
|---|---|---|---|
| CI/CD工具 | Jenkins, GitLab CI, GitHub Actions, ArgoCD | 部署时间戳、提交ID、部署环境、部署人、部署状态（成功/失败） | 定义“变更事件”的原子记录，是CFR的分子与分母的起点 |
| 监控系统 | Prometheus, Datadog, Grafana, New Relic | 错误率、延迟、饱和度、告警事件、SLO违反记录 | 提供“失败”的客观判定依据（如错误率突增、P99延迟超阈值） |
| 事件管理平台 | PagerDuty, Opsgenie, ServiceNow, Jira Service Management | 事件ID、严重级别、影响范围、关联的部署ID、事件开始/结束时间 | 确认“失败”是否被认定为事故，提供人工确认的最终标签 |
选型建议： 优先选择支持Webhook或API推送的工具，避免轮询带来的数据延迟。对于自建系统，确保CI/CD工具能输出标准化的部署事件（如CDEvents或Keptn事件格式）。
3.2 数据清洗与标准化：从原始事件到可靠SLI
原始数据存在格式不统一、时间戳偏差、重复记录、缺失字段等问题。清洗与标准化是CFR准确性的基石，主要包含以下步骤：
- 时间戳对齐： 将CI/CD的部署时间、监控的告警时间、事件平台的创建时间统一转换为UTC毫秒级时间戳，消除时区差异。
- 字段映射与补全： 建立统一的事件模型，将不同工具的字段映射到标准字段（如
deploy_id、environment、status、error_rate）。缺失的字段通过关联查询补全。 - 重复去重： 同一部署事件可能被CI/CD工具多次推送（如重试、回调），需基于
deploy_id + environment + timestamp组合键去重。 - 异常过滤： 排除非生产环境的部署、回滚操作本身（回滚是失败的结果，不是新的变更）、以及人工测试触发的部署。
- 失败判定标准化： 定义统一的失败判定规则，例如“部署后15分钟内错误率超过基线2倍”或“PagerDuty中严重级别≥P2的事件”。
标准化事件模型示例（JSON）：
{
"deploy_id": "dep-20250321-001",
"service": "payment-api",
"environment": "production",
"started_at": 1742544000000,
"finished_at": 1742544060000,
"status": "success",
"commit_sha": "a1b2c3d4",
"deployer": "jenkins-pipeline",
"failure_indicators": {
"error_rate_5min": 0.02,
"p99_latency_ms": 1200,
"has_pagerduty_alert": false
},
"is_failure": false
}3.3 采集频率与精度：平衡实时性与计算成本
采集频率直接影响CFR的时效性和系统负载。不同数据源对频率的要求不同，需根据业务场景分层设计：
| 数据源 | 推荐采集频率 | 精度要求 | 说明 |
|---|---|---|---|
| CI/CD 部署事件 | 实时（事件驱动） | 秒级 | 通过Webhook或事件总线（如Kafka）推送，延迟<5秒 |
| 监控指标（错误率、延迟） | 1分钟 | 分钟级 | Prometheus拉取或Datadog API轮询，窗口期1分钟 |
| 事件管理平台（事故记录） | 5分钟 | 分钟级 | API轮询或Webhook，事故确认通常有延迟 |
| 历史数据回填 | 每天一次 | 天级 | 用于校准和补全缺失数据，通常在凌晨低峰期执行 |
精度陷阱： 不要为了追求实时性而提高监控指标的采集频率到秒级。CFR是比率指标，分钟级精度已足够。过高的频率会增加存储成本和噪声，反而降低SLI的稳定性。
3.4 实战建议：数据管道搭建要点
- 统一事件总线： 使用Kafka或AWS EventBridge作为数据中转层，所有数据源推送事件到总线，清洗服务订阅消费，避免点对点集成。
- 幂等写入： 清洗后的数据写入存储（如Elasticsearch或ClickHouse）时，确保相同事件重复写入不会产生重复记录。
- 数据质量监控： 对采集管道设置告警，当某数据源连续15分钟无数据推送时，触发SRE介入排查。
- 保留原始事件： 清洗后的标准化数据用于CFR计算，但原始事件应保留至少30天，用于审计和口径回溯。
快速启动： 如果团队资源有限，可以先从CI/CD工具的部署事件和监控系统的错误率指标开始，手动关联确认失败。待数据管道成熟后，再接入事件管理平台实现全自动化。