线上突然出 bug 怎么找？

[christin]

求传授一点经验
昨晚 10 点多线上出 bug 了，忙到现在 1 点半了。还是我们组长帮我一起看才找到问题了。
碰到 bug 就很慌，担心影响线上业务，束手无策。求大佬指点一下。

[v2eb]

看日志呗

[charslee013]

可以从函数设计入手

一个函数出现问题只有三种情况：输入错误，输出错误，实现错误

输入错误：输入的值不符合标准导致出错

输出错误：输入的值是正确的，但输出的值并不符合预期

实现错误：输入的值是正确的，但函数执行过程出现了错误导致直接 panic 了，导致整体直接出错

前两个是整条执行链里中其中一环，前面出错会让后面一直错误下去,直到遇到后者直接 panic 才发现错误

[PerFectTime]

线上出问题不可怕，可怕的是本地不能复现

[tomari]

不打 log 的?

[dcoder]

主要靠 log
1. 你司 log service 要好用: ES, datadog 之类, 起码容易搜索.
2. 写相关模块的人, log 要输出好, 不然出了事也定位不了.

[seanzxx]

看日志呀，找出输入的数据，然后分析原因

[hahastudio]

主要靠 log
运气好一点可能有办法重现
运气再好一点可能一看 code 就明白

[haah]

难道不是查找栈堆异常信息么？

[iyaozhen]

你这个信息太少，其实也没啥，得靠积累

[还是我们组长帮我一起看才找到问题了] 这就是关键，不要问题解决了就解决了，问下你组长是怎么思考的，这个问题后续如何避免

[salmon5]

甩锅，环境问题、网络问题、CPU bug 等等

[salmon5]

谁叫的响声大，就不是谁的问题，反之亦然

[oxykr]

看日志

[westoy]

debug 也是唯手熟耳， 只要掉的坑够多， 下次跳进同样的坑就能更早出来.........

[markgor]

这个该怎么说，
我觉得就像问别人如何找到不见了的手机.
给的信息不足，目标又太广了，答复只能有万金油--看日志。
实际场景上，BUG 是谁发现了？能否复现？复现手段？这些该有吧？
好吧，就算没有，那起码知道该 BUG 影响到什么模块 /页面吧？
你最起码要知道这个 BUG 影响了什么，令到什么不符合业务状态或产生异常，然后再根据这些异常去找对应的代码，在模拟相同的场景进行复现，最后解决。
日志是定位 BUG 最好的帮手，但日志不可能一行代码一个日志记录状态，所以开发的时候就要选好地方埋点，有异常时排查方便。

[zoharSoul]

先回滚, 回头再找

[freakxx]

二分查找法 + 想象力

烂掉的代码总能抠出来

[binbinbbb]

学习他的思路，不是广告推广。有几个修 bug 思路视频可以学习

[超强！ Java 程序员居然敢直播给 SpringBoot 找 bug ？！-哔哩哔哩] https://b23.tv/aJbsgnQ

[1461665214]

arthas+排除法

[sadfQED2]

这能有什么方法？一点一点查呗，比如一个前端文案不对的 bug

1.检查前端展示逻辑，这个文案是哪里取值的
2.确定前端没问题，后端接口返回错误
3.抓包确定接口请求与返回，线下复现问题
4.排查代码日志，检查上下游依赖，检查代码 bug
5.上下游问题，根据 logid 串联上下游日志，进一步排查

你这折腾了一晚上都没确定问题在哪，是刚接手不懂业务逻辑和代码逻辑？就算不懂逻辑，一点一点抓包也排查出来了啊

[documentzhangx66]

从工程角度来说，出现 Bug ，无非就是 2 个原因：

A.设计问题：一开始的设计就是错的。

B.实现问题：在实现时出错，或者图省事没去做压力测试导致性能差，等等。

围绕这两个部分，从先易后难的思路去分析：

1.先看 2 的性能问题。从运维那里，拿到应用的 CPU 、内存、网络、存储 IO 的图表，看看有没有明显不合理的指标，比如 CPU 长时间高负载，比如存储 IO 的某个挂载点长时间的使用率（%util / 活动时间）很高，等等。

2.再看 2 的实现是否出错。此时，把日志的级别，从 INFO 或 WARNING 级别，切换到最详细的 DEBUG 级别，来分析模块与函数的调用顺序、执行时间、入参、返回结果等等，来观察与预期是否一致。

3.如果上述都没问题，就得开始检查设计问题了。这一步比较麻烦，因为需要找到比当前系统的设计者，水平更高的设计者，才能检查出问题。