1. 课程导论
1.1 平台工程：从“修路”到“铺路”的范式转变
平台工程（Platform Engineering）并非凭空出现的新概念，而是 DevOps 运动在规模化实践中遇到“认知负载过重”与“工具链碎片化”后的自然演进。其核心目标是通过构建一条内部开发者平台（IDP），为开发团队提供一条“黄金路径”，从而屏蔽底层基础设施的复杂性，让开发者专注于业务代码的交付。
与传统运维模式相比，平台工程强调“产品化”思维：
| 维度 | 传统运维模式 | 平台工程模式 |
|---|---|---|
| 交付物 | 基础设施资源（VM、网络、存储） | 自服务能力与抽象 API |
| 用户 | 运维团队内部 | 全公司开发团队（消费者） |
| 成功标准 | 资源可用性（Uptime） | 开发者体验（DX）与交付效率 |
| 变更方式 | 工单驱动、人工审批 | GitOps 驱动、自动化流水线 |
关键洞察： 平台工程不是“运维部门换个名字”，而是将基础设施视为产品，将开发者视为客户。平台团队需要像 SaaS 产品一样，定义并度量其服务质量。
1.2 服务等级目标（SLO）：平台质量的“北极星”
在平台工程语境下，SLO 不再是单纯针对业务应用的指标，而是平台团队向开发者消费者做出的服务承诺。一个没有 SLO 的平台，本质上是一个“黑盒”——开发者不知道平台何时会降级，平台团队也无法量化自身的改进效果。
平台 SLO 通常覆盖以下关键维度：
- 可用性（Availability）： 平台 API 与自服务门户的可用时间。
- 性能（Performance）： 环境创建时间、流水线触发延迟、API 响应延迟。
- 吞吐量（Throughput）： 平台每分钟可处理的环境创建请求数。
- 准确性（Accuracy）： 基础设施配置与声明式期望状态的一致性。
一个典型的平台 SLO 定义示例如下：
# 平台环境创建 SLO
service: 平台自服务门户
sli: 从开发者点击“创建环境”到环境状态变为“就绪”的耗时
threshold: P95 < 120 秒
window: 28 天
target: 99.5%
实践建议： 初期不要追求完美 SLO。从 1-2 个对开发者体验影响最大的指标开始（如“环境创建时间”），先度量，再改进，最后承诺。
1.3 基础设施即代码（IaC）：平台工程的“执行引擎”
IaC 是平台工程得以落地的技术基石。没有 IaC，平台团队无法实现环境的一致性、可重复性和版本控制。在平台工程中，IaC 扮演着三重角色：
- 抽象层： 将底层云 API 封装为模块化的 Terraform/Pulumi/CDK 组件，供开发者通过配置文件调用。
- 合规层： 通过 Policy as Code（如 OPA/Sentinel）在 IaC 执行前进行安全与合规检查。
- 观测层： IaC 的执行日志与状态变更直接关联到平台 SLO 的 SLI 数据采集。
1.4 SLO 作业模板：连接“承诺”与“执行”的桥梁
在实际平台工程落地过程中，一个常见的痛点是：SLO 定义停留在文档或监控看板上，与 IaC 代码仓库完全脱节。这导致当基础设施配置发生变更时，SLO 目标无法自动联动更新，最终造成“承诺”与“执行”两张皮。
SLO 作业模板正是为了解决这一脱节问题而设计的。它是一个结构化的、版本化的、可嵌入 IaC 仓库的 YAML/JSON 文件，用于声明式地定义：
- 平台服务的 SLO 目标与 SLI 采集方式。
- SLO 燃烧率告警策略。
- 当 SLO 违规时，IaC 流水线应执行的“作业”（如自动回滚、冻结发布、触发扩容）。
其核心价值体现在以下三个维度：
| 价值维度 | 具体说明 | 典型场景 |
|---|---|---|
| 一致性 | SLO 定义与 IaC 代码同源、同版本、同评审流程 | PR 中同时修改 Terraform 模块与 SLO 目标 |
| 自动化 | SLO 违规触发 IaC 流水线中的自动补偿作业 | 错误预算耗尽 → 自动阻止非紧急 IaC 变更 |
| 可审计 | 每一次 SLO 变更都有 Git 历史记录与责任人 | 通过 git blame 追溯 SLO 目标调整原因 |
常见误区： 不要将 SLO 作业模板设计成“万能模板”。每个平台服务（如“环境创建服务”、“CI/CD 代理服务”）应有独立的 SLO 模板，避免一个模板覆盖所有场景导致告警风暴。
1.5 本章小结
本章作为课程导论，建立了三个核心认知：
- 平台工程的本质是产品化基础设施，其成功与否取决于开发者体验。
- SLO 是度量平台质量的关键工具，必须从平台团队视角重新定义。
- IaC 是平台工程的执行引擎，而 SLO 作业模板 是将 SLO 承诺与 IaC 执行深度绑定的“胶水层”。