止损优先于找原因
故障发生时最容易犯的错误是先把原因查清楚再动手，结果是影响范围持续扩大。正确的顺序是先让扩散停下来，再在稳定状态下定位原因。止损是一个分层动作：先切断继续扩散的路径，再恢复服务，最后才谈优化。而这一切能否快速执行，取决于事前有没有可用的回滚通道、明确的回滚点，以及谁有权决定回滚。
基本信息
| 适用对象 | 发布、配置变更与批量执行引发的影响 |
|---|---|
| 动作顺序 | 停止扩散 → 恢复服务 → 定位原因 → 改进 |
| 回滚前提 | 有受控版本、有备份、有已验证的回滚通道 |
| 决策要求 | 明确谁有权决定回滚，避免等待审批延误 |
| 验证要求 | 回滚后需验证服务与数据状态，而不只是确认命令成功 |
止损手段分层
- 切断扩散：停止正在执行的批量任务，关闭变更入口或冻结发布
- 隔离范围：把异常节点从负载均衡或集群中摘除，避免继续承接流量
- 回退版本：切回上一个已验证的版本，适用于变更后立即出现的故障
- 回退配置：恢复变更前的配置并重载，适用于配置类变更
- 缓解措施：限流、降级、关闭非核心功能，为定位争取时间
- 数据侧保护：立即停止写入并保留现场，避免数据被进一步覆盖
回滚前的准备动作
回滚前的准备动作
ls -l /opt/app/releases | tail # 确认可用版本存在且完整
systemctl status myapp --no-pager # 记录当前状态，便于对比
cp -a /etc/myapp /etc/myapp.bak-$(date +%F-%H%M) # 改配置前留存副本
systemctl stop myapp # 先停止，避免新旧版本同时写数据
ln -sfn /opt/app/releases/1.4.2 /opt/app/current # 切换软链接完成版本回退
systemctl start myapp && curl -sf http://127.0.0.1:8080/health # 启动后验证
journalctl -u myapp -n 50 --no-pager | grep -i error # 回滚后是否仍有错误止损手段与代价
| 手段 | 生效速度 | 代价 |
|---|---|---|
| 停止批量任务 | 最快 | 任务半途而废，需人工收敛状态 |
| 摘除异常节点 | 快 | 剩余节点压力上升 |
| 回退版本 | 中等 | 数据兼容性需提前确认 |
| 回退配置 | 快 | 需确认进程重载行为 |
| 限流降级 | 快 | 用户可见功能受影响 |
回滚本身也需演练。常见的情况是备份存在、版本存在，但回滚脚本依赖的凭据、路径或服务顺序已经变化，实际执行时才发现通道不可用。验证方式很直接：在非生产环境完整走一次回滚流程并计时。
涉及数据结构变更的发布最难回滚：新版本写入的数据旧版本可能无法识别。这类变更应把回滚作为设计前提之一——先做兼容性设计，再考虑上线；已经写入的数据在回滚前应先判断是否可安全回退，必要时优先保留现场而不是抢时间。