发布策略与回滚
一、发布策略：蓝绿、金丝雀、滚动发布
蓝绿发布（Blue-Green）：准备两套完全一致的环境（蓝、绿），当前流量在蓝，新版本先部署到绿；验收通过后，将流量从蓝切到绿，绿变新生产，蓝可留作下次发布或回滚用。优点是一键切换、回滚也是再切一刀；代价是资源双倍，且切换是「全有全无」。
金丝雀发布（Canary）：新版本只部署到少量实例或一小部分流量（如 5%），观察错误率、延迟等指标；没问题再逐步放量（20% → 50% → 100%）。出问题则只影响少量用户，可快速回切。适合大流量、高风险变更。
滚动发布（Rolling）：不新增整批机器，而是在现有实例上逐批替换：先更新一部分节点，健康检查通过后再更新下一批，直到全部是新版本。资源占用小，但发布过程较长，且一段时间内新旧版本并存，需注意接口与数据兼容。
二、功能开关与渐进发布
功能开关（Feature Flag / Feature Toggle）：在代码里用配置或服务控制「某功能是否开启」，而不是靠「是否部署这段代码」。这样可以让部署与发布解耦：代码先上线但功能关闭，需要时再打开；可按用户、地域、比例灰度放量；出问题可立即关掉开关而不必回滚整个版本。实现方式从简单（配置文件、环境变量）到平台化（专门的功能开关服务，支持按规则、百分比、AB 实验）。注意开关不宜过多，要有清理机制，避免长期遗留「死代码」。
渐进发布：结合金丝雀与功能开关，先对内部用户或 1% 流量开放，再按指标逐步放大，直到全量。这样既控制风险，又不必一次性切全部流量。
功能开关示例：按布尔、百分比、用户列表控制
三、回滚预案与数据兼容
回滚预案：发布前就要想好「如果新版本有问题怎么退」。包括：回滚触发条件（错误率、延迟、业务指标超过阈值）、谁有权执行、具体步骤（切回蓝环境、金丝雀回切、滚动暂停并回滚已更新节点）、数据与配置是否要一起回退。蓝绿回滚通常是再切回旧环境；金丝雀是流量切回旧版本；滚动需要重新部署旧版本或从镜像/包回退。
数据兼容：发布与回滚都涉及数据与接口。数据库 schema 变更尽量向后兼容（加列不删列、先兼容新旧两版再弃旧）；接口采用兼容性版本或渐进废弃。否则回滚时旧代码可能读不懂新数据、或新代码依赖了新字段导致回滚后仍报错。宁可多一步「兼容期」发布，也不要一次性做破坏性变更。
回滚与数据兼容要点
- 发布前定义回滚条件、执行人、步骤与权限
- 蓝绿/金丝雀回滚多为流量切回；滚动需回退实例或镜像
- Schema 与接口保持向后兼容，避免回滚后数据/接口不兼容
四、发布检查清单与事后复盘
发布检查清单：把「发布前必做」固化成清单，减少遗漏。例如：变更说明与影响范围、回滚方案与负责人、依赖服务与配置就绪、监控与告警已就绪、数据库/缓存变更方案、发布窗口与通知、审批（如需要）。发布中：按步骤执行、记录时间点与操作人、观察核心指标。发布后：确认业务正常、关闭或调整金丝雀/开关、更新文档与 runbook。
事后复盘（Post-mortem）：若发布导致故障或近故障，做一次非甩锅的复盘：时间线、根因、影响、已做改进与待办。重点在改进流程与系统，而不是追责个人。把复盘结论写进文档，同步给团队，并更新检查清单与回滚预案。
发布检查清单要点
- 发布前：变更说明、回滚方案、依赖与配置、监控、审批
- 发布中：按步骤执行、记录时间与操作人、观察指标
- 发布后：确认业务、收尾开关/金丝雀、更新文档；若有故障则复盘
一句话： 发布策略：蓝绿两套一刀切、金丝雀小流量试水再放量、滚动逐批替换。功能开关让部署与发布解耦，支持灰度与紧急关闭。回滚预案与数据兼容保证能安全退回；检查清单与复盘让发布可重复、可改进。
五、小结
发布策略：蓝绿（双环境一键切换）、金丝雀（少量流量再放量）、滚动（逐批替换）。功能开关：部署与发布解耦、灰度与紧急关闭。回滚：事先定好条件与步骤，注意数据与接口兼容。检查清单与复盘：发布前中后固化步骤，故障后复盘改进。下一章进入DevOps 文化与 SRE 初探，从协作文化到 SLO、错误预算与自动化运维。