线上问题处理

一、线上问题处理面试题的4大分类

二、各分类完整回答思路

类别一：监控与发现 —— 你怎么知道线上有问题？

考察点： 你是否建立了完善的线上监控体系。

回答思路： 分三层讲——崩溃监控 → 性能监控 → 业务监控

完整回答：

"线上问题的发现，我主要通过三个层面来覆盖：

第一层是崩溃监控。 我们接入了 Bugly 或者 Firebase Crashlytics，崩溃会自动上报，实时看崩溃率。如果某个版本的崩溃率突然上涨，系统会自动告警，我们会第一时间收到通知。

第二层是性能监控。 除了崩溃，还有 ANR、卡顿、内存泄漏、启动耗时这些。我们会通过自定义的监控 SDK 或者接入第三方的性能监控平台，设置阈值告警。比如启动耗时超过 2 秒就告警。

第三层是业务监控。 有些问题不会崩溃，但会导致用户完不成某个操作，比如支付失败率上升、登录成功率下降。这些是通过埋点数据来做监控的，只要某个关键指标异常波动，就说明可能有线上问题。

另外，用户反馈也是重要的来源。 应用市场的评论、客服反馈的工单，我们都会定期查看，有时候用户比监控更早发现问题。"

类别二：定位与排查 —— 你怎么找到根因？

考察点： 你的排查思路是否系统化、是否有多种手段。

回答思路： 遵循 "从已知到未知、从粗到细" 的原则，按步骤展开。

完整回答：

"线上问题的排查，我一般会按这个顺序来推进：

第一步，看堆栈和现场信息。 如果有崩溃堆栈，先看堆栈指向哪里。同时看设备信息——机型、系统版本、内存状态、网络状况，这些 Bugly 通常都会带。

第二步，看用户操作路径。 通过埋点数据还原用户在崩溃前的操作序列，看是不是某个特定场景触发的。

第三步，看是不是聚合在特定机型或版本上。 去 Bugly 后台看分布情况，如果集中在某款机型或者某个系统版本，大概率是兼容性问题，可以针对性地去查。

第四步，尝试本地复现。 根据获取到的信息，在自己设备上模拟相同场景。复现不了就找相同机型，或者用云测平台。同时可以模拟弱网、低内存这些极端条件。

第五步，如果以上都不行，就补日志发灰度。 在可疑路径加详细日志，发一个小范围灰度包，等用户触发后把新日志捞回来分析。

整个排查过程中，我会及时把进展同步给产品和测试同事，大家一起协助提供信息，不是我一个人闷头查。"

类别三：修复与止损 —— 你怎么快速解决？

考察点： 你的应急能力和风险意识。

回答思路： 分 "短期止损" 和 "长期修复" 两个阶段。

完整回答：

"线上问题的修复，我分两步走：

第一步，先止损，不管三七二十一先把影响降到最低。 止损方式要看问题类型——如果某个功能导致崩溃，可以通过远程配置把这个功能开关关掉，让用户能正常使用 App；如果是服务端接口问题，可以联系后端同事回滚或者热修复；如果是代码问题，能走热修复就走热修复，比如 Tinker 或者 Sophix，不给用户感知到。

第二步，再彻底修复，发新版本。 找到根因之后，在代码层面做完整的修复，然后走正常的发版流程。如果问题比较严重，可能会单独发一个小版本，不等下一个大版本。

这里有个原则——线上问题，永远是先保用户，再谈技术完美。 哪怕临时方案不够优雅，只要能快速恢复用户体验，就是正确的选择。"

类别四：预防与复盘 —— 怎么防止再犯？

考察点： 你是否有复盘习惯和工程化思维。

回答思路： 从 "流程" 和 "技术" 两个维度回答。

完整回答：

"线上问题解决之后，我觉得最重要的一步就是复盘和沉淀。我会做三件事：

第一，写事故报告。 内容包括——问题现象、影响范围、根因分析、临时方案、长期方案、处理时间线。这不仅是给团队看的，也是给自己留档。

第二，补充测试用例。 这次出问题的场景，之前测试用例没有覆盖到，我会把它补充到测试用例里面，避免下个版本再出现同样的回归问题。

第三，反推流程改进。 如果这次问题是因为 Code Review 没覆盖到，或者测试环境没有模拟出线上条件，那我会推动团队的流程优化，比如在 CI 里加静态检查、或者引入更完善的测试环境。

简单说就是——不让同一个问题出现两次。 "

三、高频追问及应对话术

追问1："如果热修复也来不及呢？或者你们没有热修复能力？"

回答：
"如果热修复走不了，那就看问题的影响面。影响面很大（比如大面积崩溃），会考虑紧急发版，走应用商店的加急审核通道。影响面很小（比如只有个别用户），可以先联系用户给临时方案——比如清缓存、重装 App——同时后台把用户加进白名单，用远程配置把这个用户的功能单独关掉，保证他能正常用。如果以上都不行，那最坏的方案就是后台紧急回滚到上一个版本，不过这是最后的手段，对用户体验影响最大。"

追问2："你遇到过最棘手的线上问题是什么？怎么解决的？"

回答思路： 用 STAR 法则（场景 → 任务 → 行动 → 结果），讲一个真实的经历。如果实在没有特别棘手的，可以拿前面聊过的"并发崩溃"或者"厂商兼容性问题"来举例。

示例：
"我遇到过一个比较棘手的问题——某个版本上线后，Bugly 显示崩溃率从 0.1% 涨到了 1.2%，但堆栈指向的是系统类 libc.so，看不出是自己的哪行代码触发的。而且本地完全复现不了。

我当时做了几件事——第一，去看这个崩溃集中在哪些机型上，发现都是某品牌的某款机型。第二，去查这款机型的系统版本有没有特殊性，发现它的定制 ROM 对 Binder 通信做了修改。第三，根据用户操作路径，锁定了是我们一个频繁跨进程调用的逻辑在这个机型上触发了系统 bug。

临时方案是通过远程配置把这个机型上的那个调用频率降低，崩溃率就下来了。长期方案是重构了那块逻辑，减少了 Binder 调用的次数，并且在代码里做了 try-catch 兜底。最后崩溃率回到了 0.1% 以下，并且把这次排查过程整理成文档，供团队参考。"

追问3："你们线上崩溃率控制在多少？"

回答：
"我们目前的标准是 0.3% 以内，这是行业比较常见的及格线。头部 App 能做到 0.1% 甚至更低。我们会按版本监控，如果某个版本的崩溃率超过了 0.3%，这个版本就不会全量发布，会先暂停放量排查问题。"（如果你的项目没有这个数据，可以说"我们参考的是行业标准，目标控制在 0.3% 以内"）

四、总结回答框架（记忆口诀）

把上面所有内容浓缩成4个关键词，面试时按这个框架展开就对了：

面试时一句话总结：

"线上问题处理，我总结下来就是四个环节——能发现、能定位、能止损、能预防。每个环节都有对应的手段，而且要闭环。"

五、面试官最怕听到的"送命回答"