危机处理情景题 🚨
线上故障、紧急 Bug、生产事故的高分回答指南
目录
场景一：线上突然爆出严重 Bug
📌 场景描述
上线后用户大量投诉某核心功能不可用，客服群炸了，领导问你怎么处理。
🎯 面试官考察点
- 应急响应能力：是否能快速冷静决策
- 优先级判断：先救火还是先分析
- 团队协调：能否调动资源快速解决
- 复盘意识：问题解决后如何预防
✅ 高分回答
结构化总览：
我会分四步处理：先止血 → 定位问题 → 修复上线 → 复盘改进
第一步：先止血（最高优先级）
目标：减少用户影响范围，争取排查时间
具体动作：
| 场景 | 止血手段 |
|---|---|
| 新功能导致的问题 | 回滚到上一个稳定版本 |
| 全量影响 | 降级开关关闭该功能 |
| 灰度阶段发现 | 停止灰度扩量 |
| 影响部分用户 | 评估是否需要紧急修复 vs 等排查 |
同步动作：
- 通知相关方（产品、客服、领导）当前状态
- 明确告知："问题已知，正在处理，X 分钟后同步进展"
示例话术：
问题已经确认，我们正在紧急处理。目前先回滚到上一版本止血，预计 10 分钟内恢复，后续会同步根因分析。
第二步：快速定位问题
排查顺序（前端视角）：
1. 确认影响范围
- 全量 or 灰度？
- 全平台 or 特定浏览器/设备？
- 全用户 or 特定账号类型？
2. 复现问题
- 本地能否复现？
- 是否需要特定数据/账号？
3. 定位代码变更
- 本次上线的 commit diff
- 是否有依赖升级？
- 是否有配置变更？
4. 前后端分工排查
- 接口返回是否正常？（网络/后端问题）
- 前端渲染逻辑是否正确？
- 静态资源加载是否正常？加分点：
我会先看监控埋点数据，确认错误是集中在哪个环节，避免盲目排查浪费时间。
第三步：修复上线
决策点：热修复 vs 回滚
| 条件 | 选择 |
|---|---|
| 问题根因明确，修复简单 | 热修复 + 紧急上线 |
| 根因不明确，影响严重 | 先回滚，后续修复 |
| 回滚有风险（数据兼容性） | 热修复优先 |
上线流程（紧急情况）：
- 代码修复后 必须有人 Code Review（哪怕快速）
- 跳过完整测试，但 核心路径必须验证
- 灰度放量，确认无问题后全量
- 上线后持续观察监控 15-30 分钟
第四步：复盘改进
复盘时间：问题解决后 24-48 小时内
复盘内容：
| 维度 | 要点 |
|---|---|
| 直接原因 | 具体是哪行代码/哪个配置导致的？ |
| 根本原因 | 为什么没有在测试/灰度阶段发现？ |
| 改进措施 | 流程、技术、监控如何改进？ |
| 责任认定 | 对事不对人，重点是机制问题 |
前端侧改进措施示例：
markdown
## 技术层面
- [ ] 增加该场景的自动化测试用例
- [ ] 完善错误边界（Error Boundary）
- [ ] 加强关键路径的埋点监控
## 流程层面
- [ ] Code Review checklist 增加该类场景检查项
- [ ] 灰度策略调整（先内部 → 小流量 → 全量）
- [ ] 上线后必须有人值守观察 30 分钟💡 收尾金句
我的目标不是"把这个 Bug 修好"，而是"让这类问题不再发生"或者"发生了能更快发现和止血"。
⚠️ 常见扣分回答
| 错误表现 | 问题 |
|---|---|
| "我先看看代码" | 没有优先止血，用户还在受影响 |
| "这个是后端的问题" | 先甩锅，而不是协同解决 |
| "我不知道怎么回滚" | 暴露日常缺乏应急演练 |
| "上次也这样" | 暴露没有复盘改进机制 |
场景二：上线后发现严重性能问题
📌 场景描述
新版本上线后，用户反馈页面明显变慢，首屏加载时间从 2s 变成了 8s。
🎯 面试官考察点
- 性能问题定位能力
- 风险评估和决策能力
- 前端性能优化知识储备
✅ 高分回答
结构化总览：
我会分四步处理：评估影响 → 决定止血策略 → 定位性能瓶颈 → 优化并验证
第一步：评估影响和决策
快速评估：
1. 影响范围
- 全量用户 or 部分用户？
- 所有页面 or 特定页面？
- 首次访问 or 每次都慢？
2. 严重程度
- 是"慢"还是"不可用"？
- 核心转化路径是否受影响？
- 是否有用户流失数据？决策矩阵：
| 影响程度 | 根因是否明确 | 决策 |
|---|---|---|
| 严重（核心功能不可用） | - | 立即回滚 |
| 中等（明显变慢） | 明确 | 热修复 |
| 中等（明显变慢） | 不明确 | 回滚 + 后续排查 |
| 轻微（可接受） | - | 排期优化 |
第二步：性能问题定位
定位路径（前端视角）：
1. 网络层面
├── 资源体积是否变大？（查看打包产物）
├── 请求数量是否增加？
├── 接口响应时间是否变长？
└── CDN 是否正常？
2. 渲染层面
├── 是否有大量重渲染？（React Profiler）
├── 是否有阻塞渲染的 JS？
├── 是否有 Layout Shift？
└── 是否有内存泄漏？
3. 代码层面
├── 本次 diff 是否引入了重型依赖？
├── 是否有同步阻塞操作？
├── 图片/静态资源是否过大？
└── 是否有死循环或大量计算？快速定位工具：
| 工具 | 用途 |
|---|---|
| Lighthouse | 整体性能评分和建议 |
| Chrome DevTools Performance | 运行时性能分析 |
| Chrome DevTools Network | 网络请求分析 |
| Webpack Bundle Analyzer | 打包体积分析 |
| 线上监控平台 | 真实用户性能数据 |
第三步：常见性能问题和修复
| 问题类型 | 典型原因 | 修复方案 |
|---|---|---|
| 首屏资源过大 | 引入了大型库、未 Tree Shaking | 按需加载、代码分割 |
| 接口慢 | 后端问题、请求过多 | 接口合并、缓存、并行请求 |
| 渲染阻塞 | 同步 JS、CSS 阻塞 | async/defer、CSS 内联关键样式 |
| 重复渲染 | React 组件未优化 | useMemo、React.memo、状态下沉 |
| 图片过大 | 未压缩、未懒加载 | WebP、懒加载、CDN 裁剪 |
第四步：复盘和预防机制
建立性能防护机制：
markdown
## CI 层面
- [ ] 打包体积监控（超过阈值阻断构建）
- [ ] Lighthouse CI（性能分数低于阈值告警）
## 发布层面
- [ ] 灰度期间监控性能指标
- [ ] 核心页面性能基线告警
## 日常规范
- [ ] 引入新依赖需要评估体积影响
- [ ] 定期性能巡检💡 收尾金句
性能问题往往是"温水煮青蛙"，我会推动建立性能基线和监控，让性能退化能被及时发现，而不是等用户投诉。
场景三：半夜收到告警 CPU 飙到 100%
📌 场景描述
凌晨 2 点收到告警，某服务 CPU 使用率飙升到 100%，影响用户访问。
🎯 面试官考察点
- 应急响应流程
- 问题定位思路
- 系统全局视角
✅ 高分回答
结构化总览：
我会分三步处理：止血保可用 → 定位根因 → 修复并复盘
第一步：止血保可用
立即行动：
1. 确认影响范围
- 哪些服务/页面受影响？
- 用户是否已经无法访问？
2. 止血手段（按情况选择）
- 服务扩容（增加实例数）
- 重启服务（临时缓解）
- 流量降级（关闭非核心功能）
- 限流（保护核心链路）
3. 通知相关方
- 值班人员
- 相关负责人
- 需要的话通知客服第二步：定位根因
排查思路：
1. 最近有什么变更？
├── 代码发布？
├── 配置变更？
├── 流量突增？（运营活动/爬虫/攻击）
└── 依赖服务异常？
2. 前端可能导致的原因
├── 页面死循环导致接口轰炸
├── 轮询频率过高
├── 未节流的高频操作
└── 大量并发请求
3. 定位工具
├── 监控平台查看 QPS、错误率变化
├── 日志分析异常请求特征
└── APM 工具查看慢查询/热点第三步：复盘和预防
复盘内容：
- 为什么会发生？（直接原因 + 根因）
- 为什么没有提前发现？（监控是否覆盖？）
- 如何预防下次？（机制改进）
预防机制：
markdown
## 监控告警
- [ ] 核心指标告警阈值是否合理？
- [ ] 告警是否能及时触达？
## 架构层面
- [ ] 是否有限流熔断机制？
- [ ] 是否有自动扩缩容？
## 发布层面
- [ ] 变更是否有观察期？
- [ ] 高峰期是否禁止发布？场景四：生产环境数据被误操作
📌 场景描述
有人误执行了删除命令，生产环境部分数据丢失。
🎯 面试官考察点
- 数据安全意识
- 应急处理能力
- 预防机制认知
✅ 高分回答
结构化总览：
我会分四步处理：确认影响 → 阻止扩散 → 恢复数据 → 建立机制
第一步：确认影响范围
1. 什么数据丢失了？
- 表/库级别？还是部分记录？
- 核心业务数据还是可恢复数据？
2. 影响多少用户？
- 全量用户？还是特定用户？
3. 业务影响
- 功能完全不可用？还是部分降级？第二步：阻止继续扩散
1. 立即停止相关操作
- 确认误操作的命令/脚本已停止
- 必要时冻结相关服务写入
2. 保护现场
- 不要急于恢复操作，避免二次破坏
- 记录当前状态用于后续分析第三步：数据恢复
| 恢复方式 | 适用场景 |
|---|---|
| 从备份恢复 | 有定期备份，数据量大 |
| Binlog 回放 | MySQL，需要精确恢复 |
| 快照恢复 | 云服务有快照机制 |
| 业务侧补偿 | 数据可从其他来源重建 |
第四步：建立预防机制
markdown
## 权限管控
- [ ] 生产环境操作需要审批
- [ ] 高危操作需要二次确认
- [ ] 最小权限原则
## 技术防护
- [ ] 删除操作软删除 + 延迟清理
- [ ] 定期备份 + 验证备份可用性
- [ ] 操作审计日志
## 流程规范
- [ ] 变更操作必须有 review
- [ ] 高危操作必须双人确认💡 收尾金句
数据是最宝贵的资产。我会推动建立"删除即软删除"的规范，以及完善的备份验证机制，让误操作的影响可控可恢复。
面试追问准备
| 追问 | 要点 |
|---|---|
| 如果回滚也有问题怎么办？ | 灰度回滚、数据兼容性检查、准备 plan B |
| 如何判断要不要叫其他人？ | 影响范围大、超出能力范围、需要决策授权 |
| 复盘会怎么开？ | 时间线还原、不追责只追因、输出 action |
| 怎么平衡速度和质量？ | 核心路径必须测、非核心可简化、事后补测试 |