4. 搭建演练环境：生产 vs 沙箱

演练环境怎么搭，这事我纠结过很久。早期我总觉得，搞个隔离环境练一练就行了，安全嘛。后来吃过亏才发现——隔离环境练得再好，上了生产该崩还是崩。

这一章咱们就掰扯清楚：沙箱演练和生产演练，各自有什么坑，怎么选，怎么搭。

4.1 隔离环境（沙箱）演练

沙箱，说白了就是一套跟生产完全隔离的独立环境。数据是脱敏的，流量是模拟的，网络是封闭的。你随便折腾，炸了也不影响线上。

优点

• 安全第一：再怎么搞，不会影响真实用户。我见过有人把沙箱的数据库删了，大家哈哈一笑，重启就行。
• 可重复执行：同一个场景可以反复练，直到流程跑顺。生产上你敢这么玩？
• 新人友好：新来的同事可以在沙箱里大胆试错，积累经验。
• 成本可控：沙箱的机器配置可以比生产低，资源开销小。

缺点

• 环境差异：这是最大的坑。沙箱的配置、网络、数据量跟生产不一样，演练结果往往偏乐观。
• 缺乏真实流量：模拟的流量跟真实用户行为差太远。你想想看，沙箱里每秒100个请求，生产上每秒10万，能一样吗？
• 依赖模拟工具：故障注入工具、流量生成器本身可能有bug，导致演练结果失真。
• 团队心态不同：大家都知道是假的，紧张感不够，操作容易马虎。

4.2 生产环境灰度演练

生产环境演练，听着就让人手心冒汗。但说实话，真正有效的恢复演练，最终都得回到生产上来。关键是怎么控制风险。

我个人习惯用“灰度”的思路：不搞全量，只影响一小部分流量或节点。

灰度演练的核心原则

1. 最小爆炸半径：每次只影响1%的流量，或者1个节点。炸了也就影响一小撮用户。
2. 可观测性先行：演练前必须把监控、告警、日志都拉到位。我要求团队做到：演练开始后10秒内，相关指标必须出现在仪表盘上。
3. 一键回滚：任何演练都必须有回滚方案，而且回滚操作要能在30秒内执行完毕。
4. 避开高峰期：选在业务低峰期进行，比如凌晨2点到4点。

灰度演练的常见模式

模式	说明	适用场景
节点灰度	从集群中摘掉1个节点，对其注入故障	验证单节点故障恢复、自动扩缩容
流量灰度	将1%的流量引到演练环境或降级服务	验证降级策略、限流效果
用户灰度	只影响特定标签的用户（如内部员工）	验证数据恢复、功能回滚
地域灰度	只在某个机房或区域进行演练	验证多活架构、跨区域切换

4.3 沙箱 vs 生产：怎么选？

其实不是二选一的问题。我建议的路线是：沙箱练流程，生产验效果。

• 新场景、新脚本、新人 → 先在沙箱跑3遍以上
• 流程跑顺了、脚本稳定了 → 再到生产灰度验证
• 灰度验证通过 → 逐步扩大范围，最终全量

下面这张图是我团队常用的演练环境选择流程，你可以参考：

4.4 生产灰度演练的实操要点

如果你决定在生产上搞灰度演练，下面这几条是我踩过坑之后总结出来的硬规矩：

准备工作清单

• 确认监控覆盖：演练涉及的所有指标，必须提前配置好告警阈值。我要求团队演练前做一次“监控自检”——故意触发一个故障，看告警能不能正常发出。
• 准备回滚脚本：回滚脚本要提前写好、测试过。别等到演练出问题了再现场写脚本，那会儿手都是抖的。
• 通知相关方：至少提前24小时通知业务方、客服、运维值班人员。我曾经有一次没通知客服，结果用户投诉进来，客服一脸懵。
• 设定终止条件：明确什么情况下必须终止演练。比如：错误率超过1%、延迟增加超过50%、影响用户数超过1000。

演练执行步骤

1. 摘流量/节点：用负载均衡或服务发现机制，把目标节点从集群中摘掉。
2. 注入故障：按演练剧本注入故障（比如kill进程、模拟网络延迟）。
3. 观察指标：盯着仪表盘，看错误率、延迟、吞吐量等关键指标的变化。
4. 执行恢复：按预案执行恢复操作（比如重启服务、切换主从）。
5. 验证恢复：确认指标恢复正常，节点重新加入集群。
6. 复盘记录：记录演练过程中的异常、耗时、操作失误。

4.5 我的建议

如果你现在刚开始搭建演练体系，我建议你从沙箱起步。先跑通流程，让团队熟悉操作。等沙箱演练稳定了，再逐步引入生产灰度。

记住一个原则：沙箱是练手的地方，生产是验证的地方。两者缺一不可。