问这种问题纯属狗屎，因为不同的线上问题有不同的线上排查思路。所以当面试官问这个的时候，直接一口啐到他脸上。这种问题就好比问你做饭怎么做？这是人能回答出来的问题吗？而且大多数在校生/实习生也没有什么线上问题解决经验。

因此对于这个问题，能说出来就已经是很不错了。所以不要过度焦虑

关于这个问题我说的也不一定对，大家如果有其他更好的也可以分享在评论区。

前置：

写代码的时候，关键的路径一定要打日志，做好告警工作。由监控测反馈有线上问题肯定要比业务侧反馈要好得多。

不打日志我直接给你一电炮呢

公司也是有日志平台的，说白了就是之前的日志都在各个服务器上，然后现在为了方便查看日志。就把所有的日志都使用类似于es这种工具收集起来，然后提供一个平台来对这些日志做查询，方便排查线上事故。

所以我之前在美团的时候，公司内部其实已经搭建起来一套相对成熟的告警体系了。因此我在排查线上问题的时候，更多的还是依赖于这些监控系统进行排查。

事中处理：

先到变更日志中（美团的叫MCW，就是任何对于线上的变更发版什么的都要在这里面做记录，类似于日程表）查看最近有没有线上变更。

如果有线上变更，那大概率就是本次变更所带来的问题。所以判断一下能不能回滚。如果可以回滚的话，优先考虑回滚。

为啥说要判断能不能回滚呢？因为有的变更可能本来就是为了修改上一次的bug。

大盘追踪：

看这个是因为不是所有的线上事故都是bug。我给你举一个例子：deepseek服务爆火导致官网经常出现：“服务繁忙中，请稍后重试”。

这是bug吗？从用户的角度讲，他们没有办法正常使用服务确实就是bug。但是从deepseek后端人员的角度来讲纯粹就是流量太大了。

那我们的服务也有可能会有流量激增的情况。所以去大盘看一看是不是线上服务流量激增了，考虑做限流或者降级措施。同时看一看有没有线上接口失败率飙升的。

代码层面追踪：

抓一个相关故障的traceId追一下对应的链路，到链路追踪平台中看一看一整条链路，确定到底是哪个链路中的哪个环节出错了。是自己部门的就及时协同修改，不是的话就及时通知下游部门。

所以这一步还有一个前提就是：打好日志，不然很难追。

例如是不是代码上写死锁了？是不是代码上出现大量的创建对象了？

中间件层面追踪：

先查存储侧有没有瓶颈(MySQL 的CPU有没有飙高，主从同步延迟是否很大，有没有慢SQL。Redis是不是内存满了，走了淘汰策略。搜索引擎有没有慢Query)，把该服务所依赖的中间件的指标看一遍，这个过程中也要去看看服务接口的QPS/RT相关的监控。如果有某项指标不对劲，那顺着写入逻辑也应该很快能看出来

追踪到具体的错误了之后，不同的线上事故有不同的排查和解决方式。后续我会进行更新具体某个错误的文档。

事后：

做好复盘工作，减少线上服务因为重复的问题而引发的bug

关注我，带你了解更多代码之外的生存之道。欢迎订阅我的专栏（目前免费），后续也会持续更新。如果这篇文章帮到了你的话，就送我朵花花吧。

#牛客AI配图神器#