1. 课程导论:平台工程与SLO概述、IaC在平台工程中的角色、SLO作业模板的价值

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 扮演着三重角色:

  1. 抽象层: 将底层云 API 封装为模块化的 Terraform/Pulumi/CDK 组件,供开发者通过配置文件调用。
  2. 合规层: 通过 Policy as Code(如 OPA/Sentinel)在 IaC 执行前进行安全与合规检查。
  3. 观测层: IaC 的执行日志与状态变更直接关联到平台 SLO 的 SLI 数据采集。
平台工程中 IaC 与 SLO 的集成关系 平台工程中 IaC 与 SLO 的集成关系 开发者 提交 IaC 配置 平台 API / GitOps 触发流水线 IaC 执行引擎 Terraform / Pulumi 基础设施 K8s / 云资源 SLO 观测 SLI 采集 / 燃烧率 反馈闭环: SLO 燃烧率触发告警 → 平台自动回滚 IaC 变更

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 作业模板在 IaC 流水线中的位置 SLO 作业模板在 IaC 流水线中的位置 1. 代码提交 IaC + SLO 模板 2. 策略检查 OPA / Conftest 3. SLO 验证 燃烧率检查 4. 执行作业 Apply / Rollback SLO 作业模板示例内容: slo_target: 99.9% | burn_rate: 2.0 on_violation: rollback_last_commit notification: slack #platform-alerts
常见误区: 不要将 SLO 作业模板设计成“万能模板”。每个平台服务(如“环境创建服务”、“CI/CD 代理服务”)应有独立的 SLO 模板,避免一个模板覆盖所有场景导致告警风暴。

1.5 本章小结

本章作为课程导论,建立了三个核心认知:

  1. 平台工程的本质是产品化基础设施,其成功与否取决于开发者体验。
  2. SLO 是度量平台质量的关键工具,必须从平台团队视角重新定义。
  3. IaC 是平台工程的执行引擎,而 SLO 作业模板 是将 SLO 承诺与 IaC 执行深度绑定的“胶水层”。