上线前夜，服务器突然崩了怎么办？
上周五下午，团队准备发布新版本。一切测试通过，部署脚本也跑了一遍，就等晚上低峰期推上线。可就在执行前10分钟，监控报警：核心服务响应超时。没人敢继续点了——这时候，有没有预案，直接决定是加班到凌晨还是平稳回滚。
为什么部署必须配应急预案？
部署不是按下按钮就完事的动作，它像一次小型手术。哪怕准备再充分，也可能遇到网络抖动、配置错漏、依赖服务异常等问题。没有预案，出问题只能靠临时拍脑袋，结果往往是越忙越乱。
预案不是为了“用上”，而是为了“不怕”。就像家里备灭火器，不希望着火，但得有。
应急预案该包含什么？
一个实用的部署应急预案，至少覆盖四个层面：
- 回滚机制：能快速退回到上一稳定版本
- 关键节点检查清单：数据库连接、缓存状态、第三方接口可用性
- 通信路径：出问题找谁？值班表和联系方式必须公开可查
- 降级策略：主功能不可用时，能否切到简化模式？
举个真实例子
我们曾在一个支付模块上线时，因新引入的加密库与旧系统不兼容，导致交易签名失败。幸好预案里写了：若连续5笔交易异常，自动触发告警并暂停发布。运维按流程切换回旧版本，整个过程不到8分钟，用户几乎无感。
自动化脚本是预案的好搭档
手动操作容易出错，尤其在紧张时刻。把回滚、服务启停、状态检测写成脚本，一键执行，能极大降低压力。
# rollback.sh
#!/bin/bash
echo "开始回滚应用..."
systemctl stop app-service
git checkout release-v1.2.0 -f
npm install --production
cp config/prod.env .env
systemctl start app-service
echo "回滚完成，服务已启动"这类脚本要提前测试，并放在所有成员都能访问的位置，比如内部Git仓库的 ops/emergency 目录下。
定期演练，别让预案落灰
写好的预案如果从没试过，等于没写。建议每季度做一次“故障模拟”：比如在测试环境故意断开数据库，看团队是否能按预案快速响应。这种演练花不了几小时，但能暴露很多纸面发现不了的问题。
有次演练中我们才发现，回滚脚本依赖的一个私有镜像源，在灾备环境下根本访问不到。这种细节，不练一次真不知道。
小改动也要有应急意识
别以为只有大版本才需要预案。哪怕只是改了个按钮颜色，也可能因静态资源未刷新导致页面错乱。轻量级部署同样要有退出路径——比如 CDN 缓存强制刷新、前端资源版本号快速切换等。
预案不是负担，而是专业性的体现。当你能在10分钟内搞定一次失败发布，老板和同事记住的，从来不是你出了问题，而是你处理得有多稳。