1. 平台工程概述
1.1 平台工程的定义
平台工程（Platform Engineering）是一门设计和构建内部开发者平台（IDP）的学科，其目标是通过抽象底层基础设施的复杂性，为开发团队提供一条自服务、标准化、安全合规的交付路径。平台工程不是简单地搭建一个工具或门户，而是将运维能力、安全策略、成本管控和可靠性要求以产品化的方式交付给开发者。
核心定义：平台工程 = 内部开发者平台（IDP）的设计、构建与持续运营，使开发者能够在不理解底层基础设施细节的前提下，安全、快速地交付和运行软件。
1.2 平台工程的核心价值
平台工程通过以下四个维度为企业带来可量化的收益：
| 价值维度 | 具体表现 | 关键指标 |
|---|---|---|
| 加速交付 | 消除环境配置、CI/CD 搭建、资源申请等等待时间 | 部署频率提升 3-5 倍 |
| 降低认知负荷 | 开发者无需掌握 K8s、Terraform、网络策略等底层技能 | 新功能上线时间缩短 60% |
| 标准化与合规 | 内置安全基线、成本标签、审计日志，防止配置漂移 | 安全事件减少 80% |
| 可靠性内建 | 黄金路径自动包含健康检查、熔断、可观测性埋点 | MTTR 降低 50% |
1.3 平台工程与 DevOps 的关系
平台工程不是 DevOps 的替代品，而是 DevOps 实践在规模化阶段的自然演进。两者关系可概括为下表：
| 对比维度 | DevOps | 平台工程 |
|---|---|---|
| 核心关注点 | 文化与流程协作（打破墙） | 产品化与抽象（消除复杂性） |
| 主要受众 | 开发 + 运维团队 | 开发者（作为内部用户） |
| 交付物 | 自动化脚本、流水线、文档 | 内部开发者平台（IDP）、黄金路径、API |
| 成功标准 | 部署频率、故障恢复时间 | 开发者满意度、平台采用率、自服务占比 |
| 关系定位 | 平台工程的上层文化基础 | DevOps 的技术实现载体 |
实践建议：在推行平台工程之前，团队应已具备基本的 DevOps 文化（如持续集成、共享责任、快速反馈）。平台工程将 DevOps 的"最佳实践"固化为平台上的"默认路径"，从而降低对个人经验的依赖。
1.4 平台工程在企业中的典型应用场景
以下场景是平台工程在企业落地中最常见、价值最高的切入点：
- 环境自服务与标准化：开发者通过平台一键创建开发/测试/预发环境，环境配置、网络策略、中间件版本全部由平台模板管控，消除"环境不一致"导致的故障。
- CI/CD 黄金管道：平台内置经过可靠性验证的构建、测试、部署流水线，自动集成代码扫描、单元测试、安全审计，开发者只需关注业务代码。
- 基础设施即代码（IaC）抽象：将 Terraform、Crossplane 等 IaC 工具封装为平台 API，开发者通过 YAML 或 UI 声明资源需求，平台负责编排与状态管理。
- 变更风险评估与自动化审批：平台自动采集变更元数据（影响范围、变更类型、历史失败率），结合可靠性模型输出风险评分，驱动自动审批或人工干预——这也是本课程的核心场景。
- 可观测性与 SLO 管理：平台为每个服务自动注入日志、指标、链路追踪配置，并基于 Service Level Objective（SLO）生成可靠性仪表盘和告警规则。
1.5 平台工程参考架构
下图展示了一个典型的内部开发者平台（IDP）分层架构，清晰呈现平台工程各模块之间的协作关系：
关键认知：平台工程不是"运维工具链的简单封装"，而是以产品思维重新设计开发者体验。上图中的每一层都需要考虑变更风险——从开发者提交变更申请，到编排层执行风险评估，再到基础设施层实际部署，最后通过可观测性层验证变更效果，风险评审贯穿全流程。
1.6 平台工程与变更风险的关系
在平台工程的语境下，变更风险不再是事后救火，而是通过以下机制内建到平台中：
- 变更元数据标准化：平台强制要求每次变更附带影响范围、变更类型、回滚方案等元数据，为风险评估提供结构化输入。
- 风险评分自动化：基于历史失败率、变更涉及的服务拓扑、变更时段（如是否在封窗期）等维度，由平台自动计算风险等级。
- 任务编排驱动评审：高风险变更自动触发人工审批、灰度发布、自动化回归测试等任务；低风险变更走轻量级快速通道。
- 可靠性反馈闭环：变更后的 MTTR、故障率等指标自动回流到平台，持续优化风险模型。
本课程定位：我们将深入平台工程的"编排与抽象层"，聚焦于变更风险评估任务编排这一核心能力，讲解如何通过工作流引擎（如 Temporal、Argo Workflows）将风险评审、自动化测试、灰度发布、人工审批等步骤编排为可靠、可审计的自动化流程，并确保整个评审过程本身具备高可靠性。