1. 课程导论
1.1 发布工程的演进与SLO驱动的必然性
现代软件发布已从“手动脚本 + 运维审批”的粗放模式，演进为“高频、自动化、可观测”的工程体系。随着微服务架构、Kubernetes 基础设施和 CI/CD 流水线的普及，发布频率从月度提升到每日数百次。这种速度下，传统基于“人工检查清单”的质量控制方式已无法胜任——它既无法实时感知系统真实健康状态，也无法在故障发生前进行干预。
服务等级目标（SLO） 作为可观测性领域的核心度量，为发布工程提供了客观、量化的质量标尺。SLO 驱动的发布工程，本质上是将“用户感知的可靠性”与“发布决策”直接绑定：只有当前服务的错误预算（Error Budget）充足，且关键 SLI 处于健康阈值内，发布才被允许继续。这种机制将发布从“基于流程的审批”升级为“基于数据的自动化决策”。
核心转变： 从“发布后监控”到“发布前门禁”——SLO 使质量门禁从被动响应变为主动预防。
1.2 自助门户：平台工程的关键交付物
在平台工程（Platform Engineering）实践中，自助门户（Self-Service Portal）是开发团队与基础设施之间的“黄金路径”。它屏蔽了底层复杂性，为开发者提供标准化的发布操作界面。一个成熟的自助门户应具备以下能力：
| 能力维度 | 说明 | 与SLO的关联 |
|---|---|---|
| 发布触发 | 一键发起部署、回滚、金丝雀发布 | 触发前自动校验SLO状态 |
| 质量门禁 | 在发布流程中嵌入自动化检查点 | 门禁规则直接引用SLO阈值 |
| 阻断与放行 | 根据门禁结果自动阻断或放行流水线 | 阻断逻辑基于错误预算消耗速率 |
| 可观测性集成 | 实时展示SLI/SLO仪表盘 | 提供门禁决策的可视化依据 |
| 审计与回溯 | 记录每次发布的SLO上下文 | 支持事后分析和SLO合规审计 |
自助门户的价值在于：将SLO的复杂计算和策略执行封装为简单的“通过/阻断”信号，让开发者无需理解底层监控指标即可安全发布。
1.3 质量门禁与阻断的核心概念
质量门禁（Quality Gate）是发布流水线中的自动化检查点，而阻断（Block）是门禁检查失败后的强制执行动作。在SLO驱动的体系中，门禁与阻断的设计遵循以下原则：
- 数据驱动： 门禁规则基于实时SLI数据，而非静态配置。
- 渐进式： 不同发布阶段（预发、金丝雀、全量）对应不同严格程度的门禁。
- 可撤销： 阻断应支持人工覆盖（Break Glass），但需记录审计日志。
- 可观测： 每次阻断必须提供明确的SLO违规原因和指标上下文。
设计要点： 门禁不应只检查“当前SLO是否达标”，还应检查“发布是否会导致错误预算加速消耗”。后者更能提前发现风险。
下图展示了SLO驱动的发布工程中，自助门户、质量门禁与阻断之间的核心关系：
1.4 门禁与阻断的典型流程
一个完整的SLO驱动发布流程，通常包含以下门禁检查阶段：
- 预发检查（Pre-deploy Gate）： 验证当前生产环境的SLO是否健康。若错误预算已耗尽，直接阻断发布。
- 金丝雀检查（Canary Gate）： 将小部分流量导入新版本，实时监控金丝雀实例的SLI。若延迟或错误率超出基线，自动回滚。
- 全量检查（Full-release Gate）： 全量发布后持续观察一段时间，确保SLO未出现持续恶化趋势。
- 事后检查（Post-release Gate）： 发布完成后，更新错误预算消耗记录，用于后续发布决策。
常见误区： 门禁规则不应“一刀切”。不同服务（如核心支付链路 vs. 非关键展示页面）应有不同的SLO阈值和阻断策略。核心服务应使用更严格的错误预算消耗速率门禁。
1.5 课程目标与学习路径
本课程将围绕以下核心能力展开：
- 设计SLO驱动的门禁规则： 包括阈值设定、错误预算消耗模型、多阶段门禁策略。
- 构建自助门户的质量门禁模块： 从API设计到前端交互，实现门禁状态的可视化。
- 实现阻断与放行机制： 集成CI/CD流水线，支持自动阻断、人工覆盖和审计追溯。
- 落地平台工程最佳实践： 将门禁系统作为平台能力的一部分，降低开发者的认知负载。
通过本课程，你将掌握如何将SLO从“监控指标”转化为“发布决策引擎”，构建一个既安全又高效的发布工程体系。