1. 课程导论：DORA指标概述、变更失败率的核心地位、课程目标与学习路径
1.1 什么是DORA指标？
DORA（DevOps Research and Assessment）指标是业界衡量软件交付与运维效能的事实标准。经过多年实证研究，DORA团队将数千个团队的效能表现归纳为四个关键指标，它们共同刻画了团队从代码提交到生产环境稳定运行的完整能力。
| 指标 | 定义 | 度量单位 | 效能方向 |
|---|---|---|---|
| 部署频率（Deployment Frequency） | 团队将代码部署到生产环境的频次 | 次/天、次/周、次/月 | 越高越好 |
| 变更前置时间（Lead Time for Changes） | 从代码提交到成功部署到生产环境的时间 | 分钟、小时、天 | 越短越好 |
| 变更失败率（Change Failure Rate） | 部署到生产环境后导致服务降级、故障或回滚的变更比例 | 百分比（%） | 越低越好 |
| 故障恢复时间（Time to Restore Service） | 从生产故障发生到服务完全恢复的时间 | 分钟、小时 | 越短越好 |
关键认知：四个指标并非孤立存在。高部署频率与短前置时间代表速度，低变更失败率与短恢复时间代表稳定性。真正的精英团队必须在速度与稳定性之间取得平衡。
1.2 变更失败率的核心地位
在四个DORA指标中，变更失败率（CFR）具有特殊的枢纽地位。它不仅是稳定性的直接度量，更是连接速度与质量的桥梁。一个团队如果只追求部署频率而忽视变更失败率，最终将陷入“频繁故障-紧急修复-技术债累积”的恶性循环。
变更失败率的核心价值体现在三个层面：
- 质量门禁：CFR是部署流水线的最终质量反馈，直接反映变更引入的风险水平。
- 流程校准器：当CFR升高时，团队必须回溯前置时间、代码审查、测试覆盖等上游环节。
- 组织健康信号：长期高CFR往往预示着工程文化、技术债务或流程设计存在系统性问题。
实战经验：在SRE日常工作中，变更失败率是故障事后复盘（Postmortem）的必查指标。我们通常将CFR阈值设定为：精英团队 < 5%，高绩效团队 < 10%，中等团队 < 15%。超过15%意味着需要立即启动变更流程优化。
1.3 课程目标
本课程旨在帮助DevOps与SRE从业者建立从指标采集 → 数据建模 → 联动分析 → 改进决策的完整能力闭环。完成本课程后，你将能够：
- 精准采集与清洗：从CI/CD流水线、监控系统、事件管理平台中提取DORA原始数据。
- 构建联动模型：使用统计建模与机器学习方法，量化变更失败率与其他指标、代码特征、环境因素之间的关联。
- 识别根因模式：通过模型输出定位导致高变更失败率的具体变更类型、团队行为或技术栈特征。
- 制定改进策略：基于数据驱动决策，设计可落地的变更流程优化方案，并持续验证效果。
1.4 学习路径与章节地图
课程共30章，分为四个阶段，层层递进：
| 阶段 | 章节范围 | 核心内容 | 产出物 |
|---|---|---|---|
| 基础篇 | 第1-8章 | DORA指标详解、数据采集方案、指标计算与可视化 | 标准化指标看板 |
| 建模篇 | 第9-18章 | 特征工程、回归模型、时间序列分析、异常检测 | 变更失败率预测模型 |
| 联动篇 | 第19-25章 | 多指标联动分析、根因定位、因果推断 | 联动分析报告模板 |
| 实战篇 | 第26-30章 | 企业级案例、自动化Pipeline集成、持续改进框架 | 可落地的改进方案 |
前置要求：本课程假设学员具备基础的DevOps实践知识（CI/CD、监控告警、容器化部署），并熟悉至少一种编程语言（Python优先）。每章末尾的实战练习需要你拥有一个可访问的Kubernetes集群或云环境，建议提前准备好实验环境。