1. 课程导论：平台工程自助服务概述、SLO与变更失败率的关系、课程目标与受众
1.1 平台工程自助服务：从“工单驱动”到“能力自取”
传统运维模式下，开发团队发起资源申请、配置变更、发布上线等操作，通常需要向平台团队提交工单，等待排期与人工执行。这种模式在规模化场景下暴露出明显的瓶颈：等待时间长、上下文传递失真、平台团队成为瓶颈点。
平台工程（Platform Engineering）的核心价值在于构建一条“内部开发者平台”（IDP），将基础设施、中间件、部署流水线等能力封装为可被开发团队直接调用的自助服务。自助服务不是简单的“给权限”，而是通过标准化、可观测、带治理的API/UI，让开发者在安全边界内自主完成操作。
关键转变： 从“你提交工单，我帮你做” → “你按规范自助操作，平台保障安全与可观测”。
1.2 自助服务的三大支柱
| 支柱 | 说明 | 典型能力 |
|---|---|---|
| 能力抽象 | 将底层基础设施复杂度隐藏，暴露简洁的“服务蓝图” | 环境模板、资源规格、网络策略预设 |
| 治理内嵌 | 在自助流程中自动执行合规、配额、审批策略 | 变更前检查、成本限额、安全基线扫描 |
| 可观测反馈 | 每次自助操作的结果、影响、SLO状态实时可见 | 变更影响范围、错误预算消耗、回滚建议 |
1.3 SLO与变更失败率：为什么必须关联？
服务等级目标（SLO）定义了服务可接受的质量边界。变更失败率（Change Failure Rate, CFR）是DORA四大关键指标之一，衡量部署变更导致服务降级的比例。两者之间存在强因果关系：高变更失败率直接侵蚀错误预算，导致SLO违约。
传统做法中，SLO监控与变更管理往往是两套独立系统：SLO告警响了才去排查变更，变更失败后被动复盘。本课程的核心思路是：将变更失败率作为SLO的前置信号，在变更执行过程中实时归因，提前阻断或自动修复高风险变更。
核心洞察： 变更失败率不是事后统计数字，而是SLO的“领先指标”。通过自助服务链路中的可观测数据，可以在变更进行中判断“这次变更是否会导致SLO受损”，从而触发自动防护。
1.4 变更失败率归因的挑战
- 信号分散： 变更涉及代码、配置、基础设施、流量等多个层面，失败信号散落在不同监控系统中。
- 噪声干扰： 平台自身抖动、依赖服务波动、偶发流量高峰都可能被误判为变更失败。
- 归因延迟： 传统事后分析需要人工关联多个时间线，错过快速止损窗口。
- 自助盲区： 开发者在自助操作时，往往看不到变更对SLO的实时影响，直到用户投诉或告警触发。
1.5 课程核心框架：SLO驱动的变更失败率归因闭环
本课程围绕以下闭环结构展开，每个环节都对应具体的平台工程实践与SRE方法论：
1.6 课程目标
- 掌握平台工程自助服务的架构设计原则，理解如何将SLO作为自助服务的准入与退出标准。
- 建立变更失败率与SLO之间的量化关联模型，能够设计实时归因管道。
- 学会构建变更失败归因引擎，集成可观测数据、变更元数据与SLO燃烧率。
- 落地自动防护策略，在变更失败率超过阈值时触发自动回滚或熔断。
- 通过案例与实战，掌握在Kubernetes、服务网格、CI/CD流水线中实施SLO驱动变更防护的具体方法。
1.7 目标受众
| 角色 | 关注点 | 课程价值 |
|---|---|---|
| 平台工程师 | 构建IDP、设计自助服务API、治理策略 | 学会将SLO嵌入自助服务流程，提升平台可靠性 |
| SRE | 错误预算管理、变更风险管理、可观测性 | 掌握变更失败率归因方法，减少SLO违约事件 |
| DevOps/研发负责人 | 交付效率与稳定性平衡、团队协作流程 | 理解自助服务与SLO的联动机制，推动组织实践 |
| 架构师 | 系统韧性设计、自动化运维体系 | 获得SLO驱动变更防护的架构参考与最佳实践 |
1.8 课程预备知识
- 了解SLO、SLI、错误预算的基本概念。
- 有基本的Kubernetes和CI/CD流水线使用经验。
- 对可观测性（Metrics/Logs/Traces）有初步认识。
注意： 本课程不从头讲解SLO基础理论，但会在每个章节提供必要的上下文回顾。如果你对SLO/SLI/错误预算完全陌生，建议先阅读Google SRE白皮书相关章节。