大变更与分阶段审查

• 理解 Strangler Fig 的渐进替换思想
• 掌握 Branch by Abstraction 的抽象层做法
• 认识两者协同的分阶段步骤

Strangler Fig（绞杀者）指在不重写旧系统的前提下，用新系统逐步替换旧系统功能，最终"绞杀"旧系统，它强调增量替换与并行运行。Branch by Abstraction 指在旧实现外引入抽象层/接口，让新旧实现并存，通过抽象层逐步切换调用，最后删除旧实现。两者协同：先用 Branch by Abstraction 建立稳定契约（抽象接口），再按 Strangler Fig 思路分阶段把调用方逐步迁移到新实现，每个阶段可独立合并、测试、回滚。这使大变更被拆成可审、可验证的小步。

分阶段的本质是"把不可逆的大切换变成可逆的小步迁移"。抽象层提供"切换点"，绞杀式迁移提供"逐步替换的节奏"，两者结合让大变更可控、可回滚。

• 理解功能开关对"发布"与"上线"的解耦
• 掌握开关的实现与生命周期
• 认识开关驱动发布的安全价值

功能开关（feature flag）把代码的"发布"（部署到环境）与"上线"（对用户生效）解耦：代码先部署（默认关闭），随后通过开关远程控制新功能是否生效。这使团队能提前合并代码、按节奏灰度放量、出问题时一键关闭回退，无需回滚部署。好的开关实践包括：开关可配置化（配置中心/远程开关）、默认关闭、有到期清理机制（避免开关技术债）、开关状态可观测。发布≠上线让大变更的"部署风险"与"功能风险"分离，降低变革的爆炸半径。

功能开关是"渐进发布"的基石。它把"部署"与"暴露"分开，让回滚从"回滚版本"降级为"关闭开关"，更安全、更快速。同时支持金丝雀、灰度与 A/B 实验。

• 理解影子流量的原理
• 掌握影子流量应用与回放
• 认识影子流量对验证的价值

影子流量（shadow traffic）指把生产环境真实请求复制一份（影子请求）发送到新系统，同时不影响真实用户与旧系统，通过对比新旧系统的响应来验证新系统正确性。典型做法：网关/代理层复制流量，新系统接收后执行但不返回给用户（或仅返回给内部比对），记录结果与真实响应对账。它让新系统在"真实流量+真实用例"下经受验证，无需承担线上风险，适合验证迁移、重构、新架构的正确性与性能。影子流量是"可观测性先行"与对账的重要组成部分。

影子流量的价值在于"用真实数据在真实负载下验证新系统，而不承担线上风险"。它把验证从"模拟"升级为"真实回放"，是高风险迁移的关键验证手段。

• 理解接口契约演进的原则
• 掌握版本化、Adapter、Facade 的作用
• 认识契约兼容性保障

接口契约演进的目标是"不破坏既有调用方"。手段包括：版本化（URL/消息带版本号，新旧版本并存，平滑迁移）；Adapter（适配器，把新旧接口格式互转，让调用方无需改）；Facade（门面，对外提供统一入口，内部隐藏实现变化）。三者结合：新增版本用 Facade 统一入口，新旧版本间用 Adapter 转换，老版本逐步下线。契约演进遵循"先加后删、兼容优先"原则，配合契约测试保障兼容性。这使大变更的接口变化可渐进、可回滚。

契约是分布式系统的耦合点。演进不改契约，而是通过版本化/Adapter/Facade 提供兼容层，让调用方平稳迁移，避免一次性破坏性变更。

• 理解可观测性先行的理念
• 掌握对比指标体系的维度
• 认识指标对灰度与回滚的支撑

可观测性先行指在迁移前就建立新旧系统的对比指标体系，作为灰度放量与回滚的决策依据。指标体系包括：对账（业务结果一致性，如订单数、金额是否匹配）、错误率（新旧系统错误率对比）、延迟差（P99/P50 延迟对比）、数据一致性（关键数据是否同步一致）。这些指标在灰度/影子流量阶段持续对比，当新系统指标不劣于旧系统且稳定时才放量；一旦出现明显劣化或异常，立即回滚或停止放量。提前建立指标让决策"有数据、有边界"，而非拍脑袋。

可观测性先行把"灰度决策"从主观判断变为"指标驱动"。没有对比基线，就无法判断新系统是否真的更好或更差。指标是灰度放量与回滚的"红绿灯"。

• 理解 big bang 方式的风险
• 掌握 Knight Capital 事故的教训
• 认识避免大爆炸变更的机制

big bang change（一次性大爆炸式变更）指把大变更一次性部署上线的反模式，风险在于：失败面大、难以定位、无法渐进回滚、对生产冲击大。Knight Capital 事故中，因发布脚本误部署导致旧代码未被移除，算法在 45 分钟内产生大量错误订单，损失约 4.4 亿美元，最终破产被收购。教训包括：变更必须可验证、可回滚、有监控；发布流程需自动化与人工复核；避免依赖"只改一处不重跑"的隐式假设；高风险变更需多维防御。这警示大变更必须拆解、分阶段、加开关、可观测。

大爆炸变更的失败是"所有风险集中爆发"。Knight Capital 事件说明：不可回滚、不可监控、无防御的变更一旦出错，损失可能超出想象。分阶段、功能开关、可观测性是规避路径。

• 理解三种拆分维度
• 掌握各维度的适用场景
• 认识拆分后 PR 的可独立验证性

大变更 PR 拆分维度：按层（把数据层、服务层、接口层拆成不同 PR，逐层评审合并）；按特性（按功能垂直切片，每个 PR 完整实现一个可独立交付的功能）；按风险（按风险高低拆分，先合低风险、后合高风险，夹带风险较高的独立评审）。理想拆分是"每个 PR 可独立合并、独立验证、独立回滚"。拆分应结合三者的优点，目标是让每个 PR 足够小、上下文完整、可独立通过 CI 与测试。

PR 拆分的核心是"可独立验证"。每个 PR 合并后系统仍可运行、测试仍绿，是拆分有效性的标准。按层/特性/风险是三种常见维度，常结合使用。

• 理解指标灰度放量的机制
• 掌握回滚触发条件的设计
• 认识指标灰度的自动化

指标灰度指基于实时指标逐步放量，并把指标作为回滚触发条件。典型流程：新系统先承接少量流量（1%），持续监控错误率、延迟、正确率等指标；指标稳定则逐步放量（5%、25%、50%...），一旦某指标超过阈值（如错误率 > 0.5%、P99 延迟超基线）则自动或人工回滚/停止放量。阈值与告警需提前设定，配合功能开关快速回退。指标灰度让"放量与回滚"由数据驱动，而非主观判断。

指标灰度的本质是"用观测数据控制风险敞口"。放量是逐步增加暴露面，回滚触发条件是"安全边界"。它是可观测性先行在发布阶段的落地。

• 理解拆解原则
• 掌握拆解的具体方法
• 认识小 PR 的验证标准

拆解大变更的方法：按功能垂直切片（每个 PR 完成一个可交付功能）、按依赖顺序（先契约/数据模型→再核心逻辑→后接入层）、按关注点分离（把无关重构、格式化、依赖升级拆成独立 PR）、确保每个 PR 独立可编译、可测试、可合并。拆解时反向审查：若 PR 仍大，继续细分。小 PR 的标准是"评审者一次能完整理解、变更可独立验证、即便合并也不破坏主分支"。拆解需要设计先行，规划好依赖图与合并顺序。

拆解是"把大问题变成一系列小问题"的工程实践。它要求从设计上就规划可独立交付的切片，而非事后硬切。可独立验证是拆解质量的试金石。

• 理解设计说明的内容
• 掌握迁移计划的要素
• 认识文档对评审与执行的支撑

大变更文档通常包括：设计说明（ADR/设计文档）——背景、目标、方案取舍、架构影响、风险与权衡；迁移计划——分阶段步骤、依赖顺序、灰度与回滚方案、失败处理、干系人与时间窗口。设计说明让评审者理解"为什么这么做"，迁移计划让执行"有步骤、可回滚、可验证"。文档应在编码前完成（设计评审前置），随变更演进更新，并在评审中作为权威参考。文档化是"可观测性/可追溯性"在大变更中的体现。

大变更的文档是"决策记录与执行地图"。它让评审者有据可循、执行者有步骤可依、回滚者有预案可查。文档先行是降低大变更风险的基础。

• 理解数据迁移不可简单回滚的原因
• 掌握双写、回放、开关、对账的配合
• 认识回滚后状态恢复

数据迁移（如换表、换库、改数据格式）往往不可简单回滚，因为数据已变更。可逆方案设计：双写（新旧存储同时写入，保证新系统起步有数据）、回放（迁移期间记录操作，可重放到新存储补数据）、切换开关（读/写均可远程切换，先切读后切写）、对账（定期比对新旧数据一致性、校验差异）。回滚时：先切回旧存储读，再停止新写，通过回放/对账把新存储的增量补回旧存储，恢复双写状态（新写暂停、旧数据恢复），保证回滚后无数据丢失。整个过程需可观测、可分步。

数据迁移可逆性的关键是"系统数据可持续回放"与"双写提供缓冲"。切换开关让"读切"与"写切"分离，回滚时分步执行，配合对账与回放保证数据一致性。这是数据迁移高难度之所在。

• 理解干系人协作的重要性
• 掌握变更窗口与回滚预案的要点
• 认识跨团队沟通的机制

大变更常涉及多个团队与系统，需在分阶段计划中明确：干系人（受影响团队、上游下游、运维、SRE、业务方）及其协作点；发布窗口（选择低峰期、避开业务高峰与关键窗口，预留回滚时间）；回滚预案（每阶段都有明确回滚路径与触发条件）；跨团队沟通（提前同步变更计划、依赖关系、灰度节奏，通过变更管理/发布会/通知机制对齐）。分阶段计划的每个阶段都要纳入干系人确认与窗口安排，避免"我改完你受影响"的脱节。

大变更的失败常源于"协调不足"而非"技术问题"。干系人、窗口与预案让变更在组织层面可控，是技术与组织的双重保障。

• 理解灰度试点的选择标准
• 掌握先验证后扩展的节奏
• 认识试点验证的完整性

灰度试点选择遵循"低风险、高验证价值"：优先选影响面小、失败代价低、但能充分验证新系统核心能力的业务先行切换。例如先切内部工具/低流量业务，验证新系统的正确性、性能与稳定性；对账确认无误后再扩大到中等流量、再到核心业务。试点的验证价值在于能在小范围暴露新系统的问题，避免直接冲击核心。扩展节奏按"每步验证通过才放量"推进。试点选择要平衡"验证充分"与"风险可控"。

灰度试点的本质是"用小代价获取关键验证"。选择低风险业务降低试错成本，选择高验证价值业务保证试点能暴露真实问题，从而支撑后续扩展决策。

• 理解流量灰度的概念
• 掌握按维度切分的实现
• 认识灰度切分的稳定与可控

流量灰度（traffic split）指把流量按比例或规则切分到新旧系统。按维度切分：按 header（请求头特定值，如用户组、tenant 标记）、按 cookie（用户级标识，同一用户稳定落在同一版本）、按 IP（按 IP 段/地域切分）。其目标是"稳定（同一用户始终走同一版本，避免体验不一致）与可控（按需调整比例、定向灰度）"。实现上常用网关/代理规则或负载均衡权重。流量灰度是"功能开关+渐进发布"的落地点之一，支持定向灰度与逐步放量。

流量灰度把"给谁看新版本"与"给多少量"参数化。按维度切分（header/cookie/IP）实现稳定路由与定向灰度，是可控发布的常用手段。

• 理解分阶段审查的里程碑设置
• 掌握合并策略的演进
• 认识阶段完成的验证

分阶段审查的节奏：把大变更划分成多个里程碑（milestone），每个里程碑有明确目标、完成标准（DoD）与验证点。合并策略按阶段演进：先合契约/数据模型（定义稳定接口）→ 再合核心逻辑（可独立测试）→ 后合接入层（接通调用）。每个阶段合并前需该阶段 PR 通过评审、CI 全绿与测试，形成"阶段门禁"。节奏上避免"一个里程碑内塞太多"，应小步快跑、每阶段可独立验证与回滚。里程碑与合并策略配合让分阶段可执行、可追踪。

里程碑提供"阶段目标"，合并策略提供"阶段顺序"，阶段门禁提供"放行标准"。三者结合让分阶段审查有节奏、有验证、可回滚。

• 理解重构评审的关注点
• 掌握降低重构风险的手段
• 认识行为等价性的保障

大重构评审降低风险的手段：重点验证"行为等价性"——重构应保持行为不变，通过充分测试（尤其特性测试、契约测试、回归测试）证明重构前后行为一致；评审聚焦"结构与语义是否保持、是否引入隐性行为变化"；配合功能开关/影子流量在生产验证；拆分为小步重构（每次评审一个小的等价变换）；配合度量（如测试覆盖率、行为对比）。重构评审强调"验证等价"而非"看懂新代码"，因为风险在"行为漂移"。

重构的风险在于"行为漂移"——看似重构却悄悄改变了行为。评审+测试+影子流量共同保障等价性，小步重构让每次变更可验证、可回滚。

• 理解变更说明的内容
• 掌握决策记录（ADR）的价值
• 认识文档对评审的帮助

大 PR 的文档包括：变更说明（变更内容、动机、影响范围、测试方式、回滚方法）与决策记录（ADR——记录关键设计决策、备选方案、取舍理由）。变更说明让评审者快速理解"改了什么、为什么、影响多大"；决策记录让评审者理解"为什么这么设计"，避免重复质疑"为什么不用 X 方案"。文档应随变更演进，作为评审的参考上下文。对大型 PR，文档化是提升评审效率与可追溯性的关键。

大 PR 的评审瓶颈在于"理解上下文"。变更说明与决策记录把作者的心智模型显式化，让评审者更快进入状态、聚焦真正的问题。

• 理解分阶段合并与开关/发布的结合
• 掌握 feature flag 对合并解耦的作用
• 认识渐进发布的节奏

分阶段合并结合 feature flag：先用 feature flag 包裹新功能，使代码能提前合并（默认关闭、不影响现有行为），再按渐进发布节奏逐步放量。这样合并顺序与发布顺序解耦——代码可以按依赖顺序合并，而功能上线由开关与灰度控制。分阶段合并关注"代码可独立合并、不破坏主分支"，feature flag 保证"合并不等于上线"，渐进发布控制"何时对谁生效"。三者结合使大变更既满足可逆合并，又支持安全发布。

feature flag 让"合并"与"效果"分离，是分阶段合并的润滑剂。它允许代码提前入主干、功能由开关控制，配合渐进发布实现安全上线。

• 理解阶段门禁的完成定义
• 掌握放行标准
• 认识防止半成品滞留的机制

阶段门禁为每个迁移阶段定义"完成定义"（DoD）与"放行标准"：DoD 明确该阶段要交付什么、验证什么（如对账通过、指标达标、无阻断问题）；放行标准明确何时可以进入下一阶段（如灰度稳定 N 天、错误率为零）。防止半成品滞留的机制：阶段应有明确时间边界与责任人、超时未完成需升级处理、禁止"只做一半换人接手"、门禁未过不放行下一阶段但也防止"永远卡住"——需有推进机制与回退判断。门禁让每个阶段有"明确的完成"而非"模糊的停留"。

半成品滞留的风险是"迁移一半、状态不明、无法回滚也无法推进"。阶段门禁用"完成定义+放行标准"强制每个阶段有清晰终点，避免迁移陷入长期不完整状态。