场景题通用分析与排障框架
场景
面对“线上突然变慢”“偶现白屏”“发布后部分用户异常”等信息不完整的场景题，如何快速组织思路，既解决眼前问题，又体现系统化排障和工程治理能力？
面试速答版
场景题统一按七步回答：
- 确认现象：谁、何时、在哪里、什么版本、能否稳定复现；
- 评估影响：影响用户、核心链路、错误率和业务损失；
- 必要时止血：回滚、关闭开关、降级或切换兜底；
- 建立证据链：监控、日志、网络、性能录制和变更记录；
- 分层定位：环境 → 资源 → 网络 → 数据 → 运行时 → 渲染；
- 最小修复并验证：对照实验、灰度、观察护栏指标；
- 复盘和预防：补监控、测试、发布门禁与责任人。
回答时要区分“我会检查什么”和“什么证据能证明它就是根因”。
一、场景题考察的核心能力
场景题不是背诵排查清单，而是考察四件事：
- 优先级判断：是否知道先恢复用户可用性；
- 假设驱动排查：能否用低成本实验快速缩小范围；
- 证据意识：结论是否来自日志、指标、Trace 和对照实验；
- 体系化改进：是否能把一次故障转化为监控、测试和流程能力。
二、七步排障闭环
1. 确认现象
用“人、端、网、版本、路径、时间”描述问题：
| 维度 | 示例问题 |
|---|---|
| 人 | 全部用户、某租户还是某账号？ |
| 端 | iOS、Android、桌面端还是某浏览器？ |
| 网 | Wi-Fi、蜂窝网络、某运营商或地区？ |
| 版本 | 前端构建版本、接口版本、配置版本是什么？ |
| 路径 | 哪个入口、哪一步操作后出现？ |
| 时间 | 首次发生、持续时间、是否与发布重合？ |
“页面打不开”要进一步拆成 DNS 失败、HTML 失败、静态资源失败、脚本异常、接口失败或渲染卡死。
2. 评估影响并决定是否止血
优先确认：
- 核心交易、登录、支付等链路是否不可用；
- 错误率和受影响用户是否持续扩大；
- 是否存在数据错误、安全风险或不可逆操作；
- 是否刚刚发生代码、配置、依赖或基础设施变更。
数据正确性优先
如果问题可能导致重复支付、数据覆盖或权限越界，应立即停止相关写操作。数据错误通常比短暂不可用更难恢复。
3. 建立证据链
一个完整的前端诊断事件至少应带上：
diagnostic-context.ts
interface DiagnosticContext {
eventId: string;
traceId?: string;
sessionId: string;
userIdHash?: string;
route: string;
release: string;
configVersion?: string;
userAgent: string;
networkType?: string;
occurredAt: number;
}
证据来源包括：
- 错误监控：堆栈、Source Map、Breadcrumb；
- 性能监控：Navigation/Resource/Event Timing、Long Task；
- 网络证据：HAR、状态码、DNS/TLS/TTFB；
- 服务端日志：通过
traceId关联一次请求； - 发布记录：代码、配置、Feature Flag 和依赖变更；
- 用户会话：脱敏后的关键操作路径和页面状态。
4. 分层定位
按层排查可以避免同时修改多个变量。常见的低成本实验包括：
- 新旧版本或开关组对比；
- 清缓存、无痕模式和新账号对比；
- 切换网络、地区、浏览器和设备；
- 禁用第三方脚本或某个模块；
- 使用生产数据快照在隔离环境回放；
- 对比成功请求和失败请求的关键字段。
5. 用假设驱动，而不是漫无目的地看日志
推荐记录假设表：
| 假设 | 支持证据 | 反证 | 最小验证方式 | 状态 |
|---|---|---|---|---|
| 新版本资源混用 | 仅新版本用户失败 | 部分旧版本也失败 | 固定资源版本重试 | 待验证 |
| 接口返回脏数据 | 同一数据实体稳定失败 | Mock 数据仍失败 | 替换为合法快照 | 已排除 |
| 浏览器兼容问题 | 仅某内核版本出现 | 无 | BrowserStack 复现 | 已确认 |
每次实验尽量只改变一个变量，并记录结果。
6. 修复、灰度和验证
修复完成不等于问题结束，至少需要验证：
- 原始复现路径已经恢复；
- 错误率、性能和业务指标回到基线；
- 没有引入新的异常或数据污染；
- 灰度人群、地区和版本覆盖了原问题；
- 回滚路径仍然可用。
7. 复盘和预防
改进项应具体到“负责人、完成时间和验收方式”：
| 根因类型 | 长期改进示例 |
|---|---|
| 缺少监控 | 增加带版本和租户维度的错误率告警 |
| 测试缺口 | 为核心失败路径补 E2E 和契约测试 |
| 发布风险 | 增加灰度、自动回滚和配置审计 |
| 设计缺陷 | 补幂等、状态机和降级策略 |
| 操作失误 | 自动化高风险步骤，减少手工操作 |
三、三种题型的回答侧重点
| 题型 | 第一优先级 | 回答重点 |
|---|---|---|
| 线上故障 | 恢复可用性 | 止血、影响面、变更关联、回滚 |
| 偶现问题 | 提升可复现性 | 上下文采集、采样、回放、假设验证 |
| 方案落地 | 控制风险 | 目标、约束、分阶段交付、指标与预案 |
四、常见低质量回答
- 直接说“看控制台、看网络面板”，没有排查顺序；
- 一遇到线上问题就改代码，没有先判断是否该回滚；
- 把相关性当因果，例如“发布后出现，所以一定是前端代码”；
- 同时改多个变量，修好后仍不知道根因；
- 只修当前案例，不补监控、测试和发布防线；
- 使用“可能是缓存”等模糊表述，却不给验证方法。
常见面试问题
Q1: 线上问题应该先定位还是先回滚？
答案：看影响和风险。核心链路大面积不可用、错误持续扩大或可能破坏数据时先止血；影响有限且可以快速确认根因时可边定位边准备回滚。关键是设置明确的决策时间窗。
Q2: 问题无法复现怎么办？
答案：不要依赖手工碰运气。补齐版本、设备、网络、路由、操作序列和数据特征等上下文，聚类失败样本，与成功样本做差异对比，再通过流量回放或受控注入扩大复现概率。
Q3: 如何证明找到的是真正根因？
答案：根因应同时满足三个条件：能解释现有证据；能稳定触发问题；移除该因素后问题消失且指标恢复。仅凭时间相关或单次修复成功不够。
Q4: 为什么排障时要先看最近变更？
答案：代码、配置、依赖、数据和基础设施变更是故障的高概率来源，而且通常容易通过版本对比或回滚验证。但不能因为存在变更就跳过证据验证。
Q5: 场景题怎样体现资深程度？
答案：除了修 Bug，还要说明影响评估、止血决策、跨团队协作、证据链、灰度验证和体系化预防。资深工程师关注的是让同类问题更难再次发生。