跳到主要内容

线上故障应急响应流程

场景​

线上突然大量用户反馈页面白屏/功能异常/接口报错，作为前端你怎么处理？

应急响应流程​

标准流程：止血 → 定位 → 修复 → 复盘​

第一阶段：止血（5 分钟内）​

目标：尽快恢复服务，不要在这个阶段排查根因。

快速回滚到上一个稳定版本
# Git 回滚
git revert HEAD
git push origin main

# 或 CI/CD 平台一键回滚到上一个 Build
# Vercel/Netlify 等平台都支持 Instant Rollback
Feature Flag 紧急关闭
// 如果有 Feature Flag 机制，直接关闭有问题的功能
// 比通过完整发布流程更快

// 配置中心一键关闭
await featureFlag.update('new-checkout-flow', false);

止血手段优先级：

手段速度适用场景
Feature Flag 关闭秒级新功能导致的问题
CDN 切换到旧版本分钟级新部署导致的问题
CI/CD 回滚上一版本分钟级代码变更导致的问题
Nginx 切流/降级分钟级服务端问题影响前端
静态兜底页分钟级严重故障，切到静态页

第二阶段：定位根因​

排查清单
// 1. 查看监控平台错误日志
// - Sentry / 监控 SDK 的错误列表
// - 错误堆栈、影响用户数、设备/浏览器分布

// 2. 查看最近的变更
// - 最近是否有代码发布？
// - 是否有配置变更？
// - 是否有依赖升级？

// 3. 查看接口状态
// - 后端接口是否正常？
// - CDN 是否故障？
// - 第三方服务是否有问题？

// 4. 复现问题
// - 是所有用户还是部分用户？
// - 是否和特定浏览器/版本有关？
// - 切换网络/清缓存能否复现？

第三阶段：修复上线​

修复后要做到：

  1. 修复代码经过 Code Review
  2. 先在预发布环境验证
  3. 灰度发布：先放一小部分流量
  4. 监控指标恢复正常后再全量

第四阶段：事后复盘​

复盘模板
## 故障复盘

### 基本信息
- 故障时间：YYYY-MM-DD HH:mm ~ HH:mm
- 影响范围：XX% 用户，XX 页面
- 故障等级：P0/P1/P2

### 时间线
- HH:mm 收到告警
- HH:mm 开始排查
- HH:mm 执行回滚
- HH:mm 服务恢复

### 根因分析
描述根本原因...

### 改进措施
1. [ ] 补充监控告警
2. [ ] 完善回滚机制
3. [ ] 增加自动化测试覆盖

常见面试问题​

Q1: 线上出了故障你会怎么处理？​

答案：

先止血再排查。第一时间评估影响范围，如果影响面大，立即回滚到上一个稳定版本或关闭 Feature Flag，保证用户可用。然后再定位根因、修复、复盘。不要在止血阶段花时间排查问题。

Q2: 如何减少线上故障的发生？​

答案：

  • 灰度发布：新功能先放 5%→20%→50%→100% 流量
  • 自动化测试：核心流程 E2E 覆盖
  • Code Review：关键改动双人 Review
  • Feature Flag：大功能用开关控制
  • 监控告警：错误率、性能指标异常自动告警
  • 回滚机制：保证分钟级回滚能力

相关链接​