1. 课程导论：DORA度量体系概述、服务目录在度量落地中的核心价值、课程目标与受众
1.1 DORA度量体系概述
DORA（DevOps Research and Assessment）度量体系由Google Cloud团队基于长达六年的行业实证研究提炼而成，是当前业界衡量软件交付与运维效能的事实标准。该体系通过四个核心指标，将团队的技术能力与业务成果进行量化关联，帮助组织从“感觉”转向“数据驱动”的改进循环。
| 核心指标 | 定义 | 度量单位 | 精英级基准 |
|---|---|---|---|
| 部署频率（Deployment Frequency） | 应用代码或功能部署到生产环境的频率 | 次/天、次/周、次/月 | 按需部署（多次/天） |
| 变更前置时间（Lead Time for Changes） | 从代码提交到成功部署至生产环境所经过的时间 | 小时、天、周 | 小于1小时 |
| 变更失败率（Change Failure Rate） | 部署到生产环境后导致服务降级或需要回滚的变更比例 | 百分比（%） | 小于5% |
| 故障恢复时间（Time to Restore Service） | 从服务故障发生到完全恢复所消耗的时间 | 分钟、小时 | 小于1小时 |
关键认知：DORA指标并非孤立存在。四个指标构成一个“速度-稳定性”平衡矩阵：部署频率与变更前置时间衡量交付速度，变更失败率与故障恢复时间衡量服务稳定性。精英级团队在两项维度上均表现优异，而非在速度与稳定性之间做取舍。
1.2 服务目录在度量落地中的核心价值
在DORA度量体系的实际落地过程中，绝大多数组织面临一个共同的“数据沼泽”困境：指标数据散落在CI/CD流水线、监控系统、事件管理平台、代码仓库等多个工具链中，缺乏统一的实体关联层。服务目录（Service Catalog）正是解决这一问题的关键基础设施。
服务目录作为平台工程的核心产物，为每个服务提供唯一的“数字身份”，并承载其全生命周期的元数据。它解决了DORA度量落地中的三个根本性挑战：
- 实体归一化：将不同工具中的服务标识（如Git仓库名、Kubernetes Deployment名称、监控标签）映射到统一的服务ID，消除数据孤岛。
- 指标上下文化：为原始度量数据补充服务所属团队、技术栈、关键性等级、SLO目标等上下文信息，使指标具备可解释性。
- 聚合与下钻：支持按团队、领域、关键性等级进行指标聚合，同时允许下钻到单个服务的粒度进行根因分析。
核心价值总结：没有服务目录，DORA度量只是散落在各工具中的数字碎片；有了服务目录，这些数字才能被组织成可决策、可追溯、可改进的工程效能图谱。
1.3 课程目标与受众
本课程旨在提供一套可直接复用的工程化模板，帮助平台工程团队、SRE团队及DevOps实践者将DORA度量体系从理论概念落地为可运行、可维护、可扩展的工程系统。课程不局限于概念讲解，而是聚焦于服务目录的Schema设计、数据采集管道、指标计算引擎、可视化看板以及持续治理机制。
| 课程模块 | 核心产出 | 实践深度 |
|---|---|---|
| 服务目录Schema设计 | 可扩展的YAML/JSON模板，覆盖服务元数据、依赖关系、SLO定义 | ★★★☆☆ |
| 数据采集与集成管道 | 基于GitOps的自动化注册流程，打通CI/CD、监控、事件系统 | ★★★★☆ |
| DORA指标计算引擎 | 可配置的指标聚合与归一化计算模块，支持多时间窗口 | ★★★★☆ |
| 可视化与持续治理 | 面向不同角色的效能看板，以及目录质量巡检与告警规则 | ★★★★★ |
目标受众：
- 平台工程团队：负责建设内部开发者平台（IDP），需要将服务目录作为平台核心能力进行工程化交付。
- SRE/运维团队：承担服务稳定性与效能度量职责，需要统一的数据底座支撑DORA指标计算。
- DevOps教练与架构师：推动组织级DevOps转型，需要可落地的度量方案来量化改进效果。
- 技术管理者：需要基于数据做出工程效能决策，理解服务目录如何将指标转化为管理洞察。
前置要求：建议学员具备基础的CI/CD流水线使用经验，了解Kubernetes或类似容器编排平台的基本概念，并熟悉至少一种YAML/JSON配置格式。本课程不要求学员具备DORA度量的前期实践经验，但需要具备工程化思维和动手配置的意愿。