1. 环境差异从哪里来？（以及为什么它总在你最自信时出现）
“在我电脑上没问题”不是笑话，而是一句诊断结论：你的系统包含了太多隐式依赖。 CD 世界里，最可怕的不是差异本身，而是差异不可见、不可追溯、不可回滚。
1.1 常见差异维度清单（建议抄到你的发布检查表里）
- 依赖差异：系统库、运行时版本、容器基础镜像、外部服务版本。
- 网络差异：DNS、出口 NAT、代理、TLS、中间证书、零信任策略。
- 权限差异：IAM/RBAC、最小权限、生产保护规则、审计策略。
- 数据差异：数据量、数据分布、脏数据、权限数据、缓存预热。
- 资源差异：配额、CPU/内存、IO、限流、突发与抖动。
经验：“环境越像生产越好”不是绝对真理。更准确的说法是：staging 必须在会导致事故的维度上足够像生产。
图 1：环境漂移地图。CD 的第一件事是把差异显式化，并让它可检测、可审计、可回滚。
2. 配置/机密/开关：三类变量，三套治理
如果把它们混在一起，你会得到四种经典事故：
- “回滚镜像但没回滚配置”：事故复发，甚至更严重。
- “把机密当配置”：泄露、权限失控、无法审计。
- “把开关当配置写死”：没有秒级止损能力，只能发 hotfix。
- “把配置当代码改”：改动频繁但缺少变更治理，线上不可控。
核心原则：config 追求可回滚，secret 追求可吊销/轮换，flag 追求秒级止损。目标不同，工具与流程也应不同。
图 2：变量治理三角。把“目标”写清楚，才能选对工具：配置中心、密钥管理、开关平台各司其职。
3. 版本对齐：应用、配置、数据要能一起前进/一起撤退
“回滚”不是一个按钮，而是一个工程事实：你回滚的对象必须是一套兼容组合，而不是单个镜像或某个 YAML。 否则就会出现：镜像回滚了，但配置还在新版本；或者代码回滚了，数据库 schema 已经推进，旧代码读不懂新数据。
3.1 三个版本的关系
- App version：应用制品版本（image digest / artifact version）。
- Config version：配置版本（Git 版本、配置中心版本、render hash）。
- Schema version：数据/迁移版本（向后兼容是关键）。
目标：定义一个 release_bundle：它包含（app_digest, config_version, schema_stage, flags_snapshot, approvers, rollout_id）。回滚时回滚 bundle。
图 3：版本对齐的核心是“发布包（bundle）”。回滚不是回滚某个点，而是回滚到上一套已知好组合。
4. 一个可落地的最小实践清单（你今天就能开始做）
- 把环境差异列出来：依赖/网络/权限/数据/资源五维度，每个维度至少给出“检测点”。
- 把变量分离：config/secret/flag 三者各自有仓库/系统/审批策略。
- 把回滚对象升级为 bundle：每次发布记录 app_digest + config_version + flags_snapshot + 审批信息。
- 把兼容性写进设计：变更默认向后兼容，数据库走 expand/contract（下一章会更深）。
- 把“秒级止损”变成默认能力：关键路径功能必须可用开关快速关闭。
你现在应该能回答：
1) 我们环境差异的“清单”是什么？哪些差异是隐式漂移？
2) 配置/机密/开关分别归谁管？如何审计？如何回滚/吊销/止损？
3) 我们回滚时回滚的“对象”是什么？是否能回到上一套已知好组合？
1) 我们环境差异的“清单”是什么？哪些差异是隐式漂移？
2) 配置/机密/开关分别归谁管？如何审计？如何回滚/吊销/止损？
3) 我们回滚时回滚的“对象”是什么？是否能回到上一套已知好组合？