1. 课程导论：DORA 度量概述、平台工程与 DORA 的关系、服务目录在平台工程中的核心价值
1.1 DORA 度量概述
DORA（DevOps Research and Assessment）度量是由 Google Cloud 团队长期研究总结出的四个关键软件交付指标。它们被业界广泛接受为衡量团队 DevOps 成熟度和交付性能的黄金标准。DORA 度量聚焦于两个核心维度：交付速度与交付稳定性。
| 指标名称 | 度量维度 | 定义 | 精英级基准 |
|---|---|---|---|
| 部署频率（Deployment Frequency, DF） | 速度 | 应用向生产环境部署代码的频率 | 按需（多次/天） |
| 变更前置时间（Lead Time for Changes, LT） | 速度 | 从代码提交到成功部署到生产环境所需的时间 | 小于 1 小时 |
| 变更失败率（Change Failure Rate, CFR） | 稳定性 | 部署到生产环境后导致服务故障、回滚或修复的变更比例 | 小于 5% |
| 故障恢复时间（Time to Restore Service, TTRS） | 稳定性 | 从服务故障发生到完全恢复所需的时间 | 小于 1 小时 |
关键洞察： 精英级团队在速度和稳定性上同时达到高水平，而非在两者之间做取舍。DORA 度量证明了“加速”与“稳定”可以兼得。
1.2 平台工程与 DORA 的关系
平台工程旨在通过构建内部开发者平台（IDP），为开发者提供自助式、标准化的基础设施和工具链，从而降低认知负荷、提升开发体验。DORA 度量则是衡量平台工程成效的核心仪表盘。平台工程通过以下方式直接影响 DORA 指标：
- 标准化黄金路径： 平台提供预定义的 CI/CD 流水线、基础设施模板和部署策略，直接缩短变更前置时间（LT）并提升部署频率（DF）。
- 自动化安全与合规： 将安全扫描、策略即代码（Policy as Code）嵌入平台，在变更进入生产前自动拦截高风险操作，降低变更失败率（CFR）。
- 可观测性内置： 平台默认集成日志、指标、追踪和告警，使故障恢复时间（TTRS）从小时级缩短到分钟级。
- 消除等待与手工操作： 通过自助服务门户和环境管理，消除开发者在环境准备、权限申请上的等待时间，加速交付循环。
实践建议： 在平台工程落地初期，建议先选取“部署频率”和“变更前置时间”作为北极星指标，因为它们对平台能力的改善最为敏感。
1.3 服务目录在平台工程中的核心价值
服务目录是内部开发者平台（IDP）的数据中枢。它并非简单的服务列表，而是包含每个服务的元数据、所有权、依赖关系、运行状态、部署配置和 DORA 度量数据的结构化知识库。服务目录在平台工程中扮演着三个核心角色：
- 可发现性（Discoverability）： 开发者可以快速查找现有服务、API、文档和团队负责人，避免重复造轮子。
- 治理与合规（Governance & Compliance）： 平台团队可以基于服务目录中的元数据（如技术栈、数据分类、合规标签）实施策略，确保所有服务遵循组织标准。
- DORA 度量的数据底座： 服务目录将每个服务的部署事件、变更记录、故障事件与 DORA 指标关联，实现从“服务级”到“组织级”的交付性能透视。
1.4 服务目录驱动的 DORA 度量闭环
服务目录不仅存储静态元数据，更驱动一个持续改进的闭环：
- 采集： 平台自动从 CI/CD 工具、监控系统、事件管理平台采集每个服务的部署事件、变更记录和故障数据。
- 关联： 服务目录将原始事件与对应的服务实体关联，并计算每个服务的 DF、LT、CFR、TTRS。
- 可视化： 通过仪表盘展示服务级、团队级、组织级的 DORA 度量趋势，识别瓶颈和异常。
- 改进： 平台团队基于数据驱动决策，优化平台能力（如流水线速度、环境稳定性），形成正向循环。
常见误区： 不要将服务目录视为一次性文档项目。它需要持续维护和自动化同步，否则元数据过时会导致 DORA 度量失真，进而误导决策。