1. 课程导论：蓝绿发布与门禁的概念、为什么需要自助服务、课程目标与受众
1.1 蓝绿发布：零宕机部署的核心模式
蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零宕机、快速回滚的部署策略。在任何时刻，只有一套环境承载全部生产流量，另一套环境则处于待命或预热状态。
核心原则： 流量瞬间切换，而非逐步替换。部署风险从“修改运行中的系统”转变为“切换指向新系统的路由”。
| 特性 | 蓝环境（当前生产） | 绿环境（待发布） |
|---|---|---|
| 状态 | 承载 100% 生产流量 | 部署新版本，运行预热 |
| 流量 | 活跃（Active） | 空闲（Idle）或内部验证 |
| 回滚操作 | 保留旧版本，随时切回 | 切换失败时直接丢弃 |
| 资源成本 | 双倍基础设施（生产+待命） | 双倍基础设施（生产+待命） |
1.2 门禁：发布流程的安全闸门
在蓝绿发布中，“门禁”是指一组自动化的质量与安全校验规则，只有通过所有门禁检查的版本才被允许执行流量切换。门禁是防止有缺陷或未授权的变更进入生产环境的最后一道防线。
门禁 vs. 传统审批： 门禁是自动化、可编程的，基于预定义策略实时执行；传统审批依赖人工审核，速度慢且容易遗漏。本课程聚焦于通过 API 调用来实现自动化门禁。
| 门禁类型 | 检查内容 | 失败后果 |
|---|---|---|
| 安全门禁 | 镜像签名验证、依赖漏洞扫描、密钥泄露检测 | 阻断发布，通知安全团队 |
| 质量门禁 | 单元测试通过率、性能基准、代码覆盖率 | 回退版本，触发告警 |
| 合规门禁 | 配置漂移检测、审计日志完整性、许可证合规 | 标记为不合规，禁止切换 |
| 操作门禁 | 健康检查、就绪探针、金丝雀指标 | 自动回滚，保留蓝环境 |
1.3 为什么需要自助服务？
传统发布流程中，开发团队需要向运维团队提交工单，等待人工配置负载均衡、修改 DNS 或更新 Kubernetes Service。这种模式在微服务和多团队场景下存在明显瓶颈：
- 等待时间长： 人工操作队列导致发布周期从分钟级延长到小时级甚至天级。
- 权限僵化： 运维人员掌握所有密钥和网关权限，开发人员无法自主执行安全发布。
- 审计缺失： 人工操作难以留下可追溯的、结构化的审计记录。
- 环境差异： 不同团队对门禁规则的理解不一致，导致生产事故频发。
自助服务的价值： 通过标准化的 API 接口和预配置的安全权限模型，让开发团队能够自主调用蓝绿发布门禁，在保障安全的前提下实现“发布自助化”。运维团队从“操作者”转变为“策略制定者”。
1.4 课程目标与受众
课程目标
完成本课程后，学员将能够：
- 设计并实现 一套基于 API 调用的蓝绿发布门禁系统。
- 配置细粒度安全权限，确保只有授权实体可以触发流量切换。
- 编写自动化脚本，将门禁检查集成到 CI/CD 流水线中。
- 审计与追溯 每一次发布操作，满足合规要求。
目标受众
| 角色 | 前置知识 | 课程收益 |
|---|---|---|
| DevOps 工程师 | 熟悉 CI/CD、Kubernetes、基本 API 概念 | 掌握门禁 API 设计与自动化发布策略 |
| 平台工程师 | 了解微服务架构、网关配置 | 构建自助发布平台，提升团队效率 |
| 安全工程师 | 熟悉 OAuth2、RBAC、API 安全 | 将安全策略嵌入发布流程，实现安全左移 |
| 高级开发人员 | 有生产环境部署经验 | 理解发布门禁原理，减少生产事故 |
注意： 本课程不涉及基础 Kubernetes 安装或基础 CI/CD 工具配置。学员应具备至少 1 年以上的 DevOps 或相关领域实践经验。