上周客户老张急匆匆打电话来：‘我们刚做完红蓝对抗，系统卡了半小时，订单丢了二十多个，客服电话被打爆……这演练是不是搞得太猛了？’
不是演练本身吓人，是没选对时间、没做隔离
很多团队一听说‘攻防演练’，下意识就想到停业务、切流量、全员戒备。其实真没必要。某电商公司去年在双十二前两周做了次实战化演练，全程在影子库+灰度流量上跑，生产订单照常处理，连前端用户都没感知——后台日志里悄悄跑了3000多次SQL注入探测，漏洞当场被WAF拦截并告警，运维顺手打了补丁。
影响大的，往往是那几个‘没想到’
比如测试环境用的是单节点Redis，生产却是集群；演练时压测脚本只刷首页，结果上线后支付回调接口因连接池耗尽雪崩；再比如安全团队发了个模拟钓鱼邮件，结果HR部门误点链接触发了全公司邮箱自动转发规则……这些都不是技术多难，而是跨团队信息没对齐。
几个踩过坑的实操建议：
• 演练前拉一次三方对齐会：开发、运维、DBA、业务方都坐一起，把关键链路画成流程图，标出哪些环节绝对不能动（比如库存扣减、资金流水）；
• 流量打标：所有演练请求加X-Test-Mode: true头，网关层直接路由到沙箱服务，数据库写操作自动落影子表；
• 预设熔断开关：
if (request.getHeader("X-Test-Mode").equals("true")) {
disablePaymentService(); // 关闭真实支付
enableMockOrderService(); // 启用模拟下单
}某物流SaaS厂商就是靠这个，三年做了17次红蓝对抗，零生产事故。他们说：‘别把演练当考试，当成给系统做一次‘压力按摩’——力度够、不伤筋、还舒坦。’
真正让业务抖三抖的，从来不是黑客的攻击，而是自己没想清楚‘哪里能试、哪里不能碰、碰了怎么兜住’。