配置中心如何做变更演练？
简化版
配置变更演练是在可控范围内验证“发布、发现异常、停止扩量、回滚、实例追平”整条链路。 演练要选可逆场景，定义影响范围、量化成功标准和停止条件，先验证后灰度，不能在生产环境随意改一个错误值。
详细版
演练前写清假设，例如“错误超时值发布后，3 分钟内告警，5 分钟内全部灰度实例恢复旧内容”。 准备基线指标、目标实例、观察人、回滚版本和应急联系人。 首次演练不要选择密钥、资金规则或会产生不可逆数据的配置。
演练可覆盖发布中断、客户端离线、错误值、配置中心不可用和回滚时实例重启。 平台不仅统计服务端发布，还依据客户端上报确认期望版本、实际版本与加载结果。 结束后核对发现时间、恢复时间、未追平实例和业务影响，并自动清理临时配置。
完整版教学
一、演练验证的是恢复能力
真实失败可能发生在审批、存储、通知、客户端解析、动态应用或回滚中的任一环节。 只验证“控制台能发布”不能证明端到端可靠。 合格演练应验证发布可控、异常可见、影响可界定、旧值可恢复、离线实例可追平以及全程可审计。
演练产物不是成功截图，而是有证据的恢复能力与待改进项。
二、成功标准必须量化
例如灰度 5 个实例，将连接超时从 800 ms 调到 300 ms。 若错误率连续 2 分钟比基线高 1 个百分点，则立即停止并回滚。
| 指标 | 目标 | 证据 |
|---|---|---|
| MTTD | 小于 3 分钟 | 告警事件 |
| MTTR | 小于 5 分钟 | 版本上报 |
| 影响范围 | 仅 5 个实例 | 灰度命中日志 |
| 版本收敛率 | 本次目标且应在线实例 100% | 客户端心跳与目标快照 |
没有阈值和时间窗口，结束时只能凭感觉宣布成功。
三、场景应分层递进
测试环境先验证格式错误、越界值和跨字段约束能被发布前校验拦截。 预发布环境再验证客户端解析失败时保留最后正确版本。 生产只做小范围、可逆演练，并逐步加入通知延迟、节点不可用、客户端断网重连等变量。 一次只注入一个主要故障，才能准确归因。
四、脚本必须自带刹车
脚本记录当前版本、目标版本、选择器、负责人、观察窗口、扩量条件和回滚入口。 任何参与者都要清楚谁有权中止。
baselineVersion: 731
targetInstances: 5
observe: 10m
abortWhen: error_rate_delta >= 1%
rollbackTo: 731
maxDuration: 30m回滚权限要提前验证，不能故障发生后才发现审批人不在线。
五、确认客户端真正生效
服务端写入成功、通知发送成功、客户端应用成功是三件事。 客户端上报实例标识、配置键、实际版本、加载时间和结果摘要。 发布时目标快照有 100 个实例而只有 98 个回到旧版本时，不能直接宣布结束或把另外 2 个从分母中静默删除。 要识别它们是离线、网络隔离、解析失败还是已经缩容：确认缩容的实例可从目标集合移除；仍应服务但暂时离线的实例要单列，并在重连后追平。
六、回滚本身也要演练
回滚应创建一个引用历史内容的新发布版本，不能删除最新记录来伪造历史。 客户端以当前期望版本收敛，避免旧通知晚到后再次覆盖。 若配置已触发不可逆外部行为，恢复旧值无法撤销结果，因此这类变更需要独立补偿预案。 多个相互依赖的键应作为配置集切换，避免只回滚一半。
七、复盘形成闭环
按时间线记录发布、首个异常、告警、决策、回滚和追平。 区分自动告警和人工偶然发现；后者说明监控仍有缺口。 缺陷要有负责人和截止时间，下一次演练先验证修复。 临时白名单、灰度规则和测试值必须自动过期并人工复核清理结果。
八、常见误区与追问
- 误区：演练就是在生产改一个错误值。 没有范围和刹车的注入是在制造事故。
- 误区：控制台显示成功就结束。 必须用客户端版本和业务指标确认。
- 误区：只练发布，不练回滚。 回滚权限和追平链路同样会失效。
- 误区：演练时关闭告警以减少噪声。 这会使关键发现能力无法验证。
- 追问：生产演练如何降风险？ 选择可逆项、小范围灰度，并实时值守。
- 追问：实例离线怎么办？ 记为未收敛，重连后拉取当前版本，必要时隔离。
- 追问：多久演练一次？ 按业务等级和变更频率制定，并轮换故障场景。
九、加强记忆
- 用量化假设定义演练目标。
- 从隔离环境到生产小流量逐级验证。
- 用业务指标与客户端版本判断结果。
- 把停止、回滚、追平和审计写进脚本。
- 清理临时状态，用复盘缺陷驱动下一轮。