1. 课程导论：为什么需要SLO驱动DORA度量？自助服务平台稳定性的核心挑战与价值
1.1 平台工程的承诺与现实鸿沟
平台工程团队投入大量资源构建内部开发者平台（IDP），承诺“提升开发者体验”与“加速交付”。然而，在实际运营中，平台本身往往成为新的不稳定源：
- 基础设施漂移：自助服务降低了变更门槛，但缺乏一致性治理导致配置漂移。
- 黑盒依赖：开发者调用平台API，却无法感知底层资源瓶颈或故障。
- 度量脱节：平台团队关注CPU/内存，业务团队关注交付速度，双方缺乏统一的稳定性语言。
核心矛盾：自助服务平台在提升“交付速度”的同时，往往牺牲了“运行稳定性”。DORA度量（部署频率、变更前置时间、变更失败率、恢复时间）与SLO（服务等级目标）的割裂，是这一矛盾的根源。
1.2 从DORA到SLO：度量体系的演进
DORA四指标衡量的是交付效能，而SLO衡量的是运行可靠性。两者必须对齐，才能形成完整的稳定性闭环。
| 维度 | DORA指标 | SLO指标 | 脱节后果 |
|---|---|---|---|
| 速度 | 部署频率、变更前置时间 | 请求延迟（p95/p99） | 频繁部署导致延迟劣化，用户感知下降 |
| 质量 | 变更失败率 | 错误率（SLI） | 低失败率但高错误率，系统“可用但不可靠” |
| 恢复 | 恢复时间（MTTR） | 可用性（SLO目标） | 恢复快但频繁中断，SLO违约累积 |
当DORA指标与SLO指标独立监控时，平台团队容易陷入“部署很快但系统很慢”的困境。SLO驱动DORA度量的本质，是将可靠性约束嵌入到交付效能度量中。
1.3 自助服务平台稳定性的三大核心挑战
- 多租户资源争抢：一个团队的突发流量可能影响其他团队的SLO，而平台缺乏动态隔离机制。
- 变更爆炸半径：自助服务允许开发者直接修改基础设施配置，一次错误变更可能波及整个集群。
- 可观测性碎片化：每个团队使用不同的监控工具，平台无法聚合全局SLO视图，故障定位耗时数小时。
案例提示：某金融科技平台在推行自助服务后，部署频率提升3倍，但p99延迟从200ms飙升至2s。原因在于开发者频繁创建无状态Pod，导致控制平面过载——平台团队没有将“控制平面响应时间”纳入SLO。
1.4 SLO驱动DORA度量的核心价值
将SLO作为DORA度量的前置条件，能够为平台带来以下价值：
- 统一语言：平台团队与业务团队使用相同的SLO目标沟通稳定性，避免“我觉得系统很稳”的主观判断。
- 风险前置：在变更部署前，通过SLO预算检查自动阻断高风险变更，降低变更失败率。
- 反馈闭环：DORA指标的变化反向驱动SLO调整，形成“交付→观测→优化”的持续改进循环。
1.5 课程路线图：从理论到工程落地
本课程将围绕以下主线展开：
| 阶段 | 核心内容 | 产出物 |
|---|---|---|
| 基础篇 | SLO/SLI/错误预算设计、DORA指标校准 | 平台SLO定义模板 |
| 集成篇 | SLO引擎与CI/CD流水线集成、自助服务门禁 | 变更阻断策略 |
| 运营篇 | 多租户SLO隔离、燃烧率告警、故障复盘 | SLO仪表盘与告警规则 |
| 进阶篇 | SLO驱动容量规划、成本优化、平台演进 | 平台稳定性成熟度模型 |
前置要求：建议学员具备基本的Kubernetes操作经验，了解Prometheus/Grafana监控栈，并熟悉CI/CD基本概念。本课程不涉及基础语法教学，聚焦于SLO与DORA的工程化落地。