灰度发布方案应回答：先让谁使用新功能，凭什么扩大范围，出现什么情况暂停，以及如何处理已经产生的结果。把计划写成“先开一部分用户，没问题就全量”还不够，因为“一部分”“没问题”和“回退”都需要对应明确对象与动作。
一份能执行的方案，通常包含开放范围、分配规则、阶段条件、观察指标、决策负责人和回退预案。具体比例与时间窗口取决于业务周期、流量、风险和恢复能力，没有一组放量数字可以直接套给所有产品。
先区分灰度发布与A/B测试
灰度发布主要控制新功能的开放范围与运行风险；A/B测试则通过合适的实验设计比较不同方案的效果。一个功能可以先灰度检查运行，再进行实验；也可以在逐步开放的过程中收集反馈，但这些反馈不自动构成方案优劣的因果证据。
LaunchDarkly的发布方式文档也区分固定比例、渐进放量、带指标监控的放量和实验。这里借用的是目标划分，不意味着所有团队都需要同一平台。涉及实验分组、指标分析和结果判断时，可参考A/B测试的完整方法。
还要区分代码部署与功能开放。代码已经进入生产环境，可能仍未对用户可见；功能入口关闭，也可能仍有后台任务继续运行。方案应分别记录版本与开放规则，避免以“部署成功”代替“用户已经能正确使用”。
开放对象要选到能保持流程一致
面向个人的功能可以按账号分配；企业协作功能往往需要考虑租户或组织。若同一团队一半成员看到新转派流程，另一半仍按旧规则处理，同一张工单可能产生不同理解。此时仅按用户随机挑选，未必符合业务边界。
| 分配对象 | 适合考虑的情况 | 要检查的偏差 |
|---|---|---|
| 账号 | 相对独立的个人操作 | 多设备、退出后重新登录是否改变分组 |
| 租户或组织 | 共享数据、权限和协作流程 | 少数大租户可能占据大量实际操作 |
| 设备或应用版本 | 受客户端能力限制的功能 | 同一账号跨端行为是否不一致 |
| 明确的试点名单 | 需要提前支持与反馈的有限开放 | 试点使用方式是否足以代表后续对象 |
“开放10%的租户”不等于“承担10%的业务流量”。除了对象数量，还应观察实际触达的人数、任务量和数据规模。内部员工也可能不了解真实客户的使用节奏，内部通过不能直接替代外部场景观察。
把不符合前置条件的人群列为排除项，例如客户端版本不支持、必要配置未完成或正在执行不兼容的旧流程。排除条件要有依据，并说明何时能重新进入范围。
确定放量门槛前，可以先做一次上线前失败预演，识别必须观察的信号和需要提前准备的处理动作。
每个阶段都写进入、观察与结束条件
阶段可以按可控试点、扩大覆盖和全面开放组织，但具体安排要由团队确定。下面展示的是计划结构，不是固定发布节奏；阶段负责人需要在执行前补齐可用数据、明确门槛与观察窗口。
| 阶段 | 进入前确认 | 本阶段重点 | 何时进入下一阶段 |
|---|---|---|---|
| 有限试点 | 目标名单、支持渠道、监控与回退均准备好 | 真实主路径和关键异常能否完成 | 预定场景获得足够观察，未触发停止条件 |
| 扩大覆盖 | 新对象符合条件，试点问题已处理 | 数据规模、并发和使用差异是否带来新问题 | 达到本阶段预先确认的运行与业务门槛 |
| 全面开放 | 遗留问题可接受，支持与运维能承接 | 剩余人群、旧流程和版本兼容 | 完成开放后继续观察，并安排清理临时配置 |
每阶段至少记录开始时间、实际开放规则、观察数据截止时间和决策时间。这些时间可能不同：刚结束的任务还没进入统计结果，就不能拿当前空白报表宣布没有问题。观察窗口应覆盖与该功能有关的操作过程，例如创建到完成的完整链路，而不是只覆盖入口点击。
放量前先确认数据真的收到了
“错误数为0”可能代表没有错误，也可能代表没有收集到事件。应先核对开放对象有没有实际使用、对应的版本或分组标识是否正确、结果事件是否收到，以及监控延迟是否已经过去。
LaunchDarkly的发布健康检查专门核对评估数据、指标事件与分配对象的一致性。对任何平台，这都提醒团队先检验观测链路，再解释曲线。
指标表需要同时包含业务结果与保护条件。对工单转派而言，可能观察转派成功率、结果等待时间、重复转派、权限拒绝和接收者发现任务的情况。选哪些指标应由此次变化及风险决定，不能为了看板丰富而把全站指标全部搬进来。
指标名称：［具体业务事件或性能项］ 统计对象：［新功能开放对象，如何识别］ 分子与分母：［失败/完成/触达的明确口径］ 时间窗口及数据延迟：［填写］ 正常参考：［历史同口径数据或当前对照，注明差异］ 暂停/回退门槛：［由产品、研发和运行负责人确认］ 触发后动作：［先停止放量、关闭入口或进入回退流程］ 监控负责人和替补：［填写］
低流量阶段应同时看事件明细与任务是否走完。没有发生投诉不等于功能正常，没有足够使用也不等于可以放量。数据不足时保留“继续观察”这个结论，不必在“通过”和“失败”之间强行二选一。
暂停放量、关闭功能和回滚数据是不同动作
暂停放量是暂不扩大范围，当前用户可能仍在使用；关闭功能是让后续请求回到约定路径；数据回滚则涉及已经写入的记录。发出的通知、完成的付款或外部系统动作，通常不能因为关闭开关就自动消失。
本次回退预案应明确：已经开始的任务继续完成还是停止，新版本产生的数据能否被旧版本读取，失败与重复任务如何核对，由谁告知受影响用户。如果只能阻止新增任务，却不能恢复已有结果，要提前说明这一限制。
- 确定触发人：谁可以暂停，谁可以执行关闭或回滚，负责人不在时由谁接替。
- 准备实施步骤：目标环境、配置项、前后状态和核对方式要具体，避免临时凭记忆操作。
- 演练恢复路径：在适合的环境验证关闭入口、旧流程承接和在途任务处理，不把“有开关”当作可回退证明。
- 保留事件记录：记录影响对象、开始结束时间、操作和结果，便于判断是否可以重新开放。
涉及实现方案时，可以把这些要求放进技术方案的发布与回滚安排，与研发共同确认。
每次放量留下一个明确决定
放量检查不需要长会，但必须有明确结论：扩大、维持观察、暂停新增或回退。记录支持结论的证据、尚未解释的异常、负责人和下次检查时间。不能一边说“有点异常，再看看”，一边让定时配置继续自动扩大范围。
可以在墨刀白板上并排整理当前阶段、开放对象、指标口径、待处理问题与决定，把真实监控链接附在相关卡片旁。白板服务计划与协作，生产分流、指标采集和回退仍由实际工程系统执行。
全面开放后，还应核对长期保留的功能开关、旧路径、监控和帮助文档。临时开关如果无人负责，可能在几个月后让新成员难以判断当前行为。将需要保留的能力与可清理的发布配置分开，给每项清理明确责任，灰度方案才真正完成收尾。
官方参考：LaunchDarkly发布方式、发布健康检查。
