1. 课程导论：平台工程与自助服务的定义、DORA 度量简介、模板标准化的重要性
1.1 平台工程：从“修路”到“铺路”的范式转变
平台工程（Platform Engineering）并非简单的“运维工具链升级”，而是一种产品化思维的落地。其核心目标是通过构建一个内部开发者平台（IDP），为开发团队提供一条“铺好的路”——即标准化的自助服务能力，从而降低认知负荷，让开发者专注于业务逻辑而非基础设施。
核心定义：平台工程是设计和构建一组内部产品（平台）的学科，这些产品通过自助服务能力，抽象底层复杂性，为开发者提供安全、高效、一致的交付路径。
1.2 自助服务：开发者体验的“黄金路径”
自助服务是平台工程的核心交互模式。它意味着开发者无需等待运维团队手动创建环境、配置 CI/CD 或申请资源，而是通过平台提供的 UI、CLI 或 API 在几分钟内完成操作。
| 维度 | 传统模式（工单驱动） | 自助服务模式（平台驱动） |
|---|---|---|
| 交付速度 | 数小时到数天（排队等待） | 分钟级（即时响应） |
| 一致性 | 依赖个人经验，配置漂移严重 | 模板化、版本化，环境高度一致 |
| 认知负荷 | 开发者需掌握 K8s、Terraform 等细节 | 平台抽象复杂性，开发者仅需关注业务参数 |
| 安全合规 | 事后审计，难以追溯 | 策略即代码，前置校验，天然合规 |
1.3 DORA 度量：衡量平台效能的“金标准”
DORA（DevOps Research and Assessment）度量是业界公认的衡量软件交付与运维效能的核心指标。平台工程的最终价值，必须通过 DORA 指标的改善来证明。
- 部署频率（Deployment Frequency）： 应用向生产环境部署的频率。高频部署代表更快的价值交付。
- 变更前置时间（Lead Time for Changes）： 从代码提交到成功运行在生产环境的耗时。时间越短，响应市场越快。
- 变更失败率（Change Failure Rate）： 部署导致服务降级或中断的比例。低失败率代表平台稳定性高。
- 故障恢复时间（Time to Restore Service）： 从服务中断到完全恢复的耗时。快速恢复代表平台韧性好。
平台工程与 DORA 的关系： 平台工程通过标准化模板和自助服务，直接缩短变更前置时间、提升部署频率；通过内置的自动化测试和安全扫描，降低变更失败率；通过一键回滚和自愈能力，缩短故障恢复时间。
1.4 模板标准化：从“手工作坊”到“工业化生产”
模板标准化是连接平台工程与 DORA 度量的桥梁。没有标准化的模板，自助服务将沦为“自助混乱”——每个团队创建的环境、配置的流水线、使用的资源规格都各不相同，导致运维成本激增、安全漏洞频发。
标准化的核心价值体现在三个层面：
- 可预测性： 所有通过模板创建的资源，其配置、版本、安全基线完全一致，消除“环境差异”带来的故障。
- 可治理性： 模板作为“策略即代码”的载体，内置了组织级的合规要求、成本标签和安全策略，实现前置治理。
- 可度量性： 标准化的模板暴露了统一的度量接口（如部署时长、资源利用率），使得 DORA 指标的采集和分析成为可能。
常见误区： 模板标准化不等于“一刀切”。优秀的平台工程实践会提供“黄金路径”模板（推荐配置）和“自定义路径”模板（允许在约束范围内调整参数），在标准化与灵活性之间取得平衡。
1.5 本章小结：三位一体的课程基石
本课程将围绕“平台工程”、“自助服务”与“DORA 度量”三个核心概念展开，而模板标准化是贯穿始终的实践主线。在后续章节中，我们将深入探讨如何设计、构建、治理和迭代标准化模板，并通过 DORA 度量持续验证平台工程的投资回报率（ROI）。
关键记忆点： 平台工程是战略，自助服务是交互模式，DORA 度量是验证手段，模板标准化是落地载体。四者缺一不可，共同构成现代软件交付的“飞轮效应”。