这是一个创建于 1335 天前的主题，其中的信息可能已经有所发展或是发生改变。
求传授一点经验
昨晚 10 点多线上出 bug 了，忙到现在 1 点半了。还是我们组长帮我一起看才找到问题了。
碰到 bug 就很慌，担心影响线上业务，束手无策。求大佬指点一下。
第 1 条附言 2022-05-02 11:35:07 +08:00
也不一定要按照我的问题提出解决方法，也可以是各位在工作中总结出来的好的解决方案
 | 1 v2eb 2022-05-02 01:38:50 +08:00 via Android 看日志呗 |
 | 2 charslee013 2022-05-02 02:21:30 +08:00  4 可以从函数设计入手 一个函数出现问题只有三种情况：输入错误，输出错误，实现错误 输入错误：输入的值不符合标准导致出错 输出错误：输入的值是正确的，但输出的值并不符合预期 实现错误：输入的值是正确的，但函数执行过程出现了错误导致直接 panic 了，导致整体直接出错 前两个是整条执行链里中其中一环，前面出错会让后面一直错误下去,直到遇到后者直接 panic 才发现错误 |
 | 3 PerFectTime 2022-05-02 03:02:15 +08:00 线上出问题不可怕，可怕的是本地不能复现 |
 | 4 tomari 2022-05-02 03:19:13 +08:00 不打 log 的? |
 | 5 dcoder 2022-05-02 07:23:16 +08:00 主要靠 log 1. 你司 log service 要好用: ES, datadog 之类, 起码容易搜索. 2. 写相关模块的人, log 要输出好, 不然出了事也定位不了. |
 | 6 seanzxx 2022-05-02 08:14:12 +08:00 via iPhone 看日志呀，找出输入的数据，然后分析原因 |
 | 7 hahastudio 2022-05-02 09:26:25 +08:00 主要靠 log 运气好一点可能有办法重现 运气再好一点可能一看 code 就明白 |
 | 8 haah 2022-05-02 09:51:11 +08:00 难道不是查找栈堆异常信息么？ |
 | 9 iyaozhen 2022-05-02 10:06:34 +08:00 你这个信息太少，其实也没啥，得靠积累 [还是我们组长帮我一起看才找到问题了] 这就是关键，不要问题解决了就解决了，问下你组长是怎么思考的，这个问题后续如何避免 |
 | 10 salmon5 2022-05-02 10:17:18 +08:00 甩锅，环境问题、网络问题、CPU bug 等等 |
| 11 salmon5 2022-05-02 10:19:01 +08:00 谁叫的响声大，就不是谁的问题，反之亦然 |
 | 12 oxykr 2022-05-02 10:28:53 +08:00 看日志 |
 | 13 westoy 2022-05-02 10:41:37 +08:00 debug 也是唯手熟耳， 只要掉的坑够多， 下次跳进同样的坑就能更早出来......... |
 | 14 markgor 2022-05-02 11:06:25 +08:00 这个该怎么说， 我觉得就像问别人如何找到不见了的手机. 给的信息不足，目标又太广了，答复只能有万金油--看日志。 实际场景上，BUG 是谁发现了？能否复现？复现手段？这些该有吧？ 好吧，就算没有，那起码知道该 BUG 影响到什么模块 /页面吧？ 你最起码要知道这个 BUG 影响了什么，令到什么不符合业务状态或产生异常，然后再根据这些异常去找对应的代码，在模拟相同的场景进行复现，最后解决。 日志是定位 BUG 最好的帮手，但日志不可能一行代码一个日志记录状态，所以开发的时候就要选好地方埋点，有异常时排查方便。 |
 | 15 zoharSoul 2022-05-02 14:05:05 +08:00 先回滚, 回头再找 |
 | 16 metamask 2022-05-02 14:36:18 +08:00 二分查找法 + 想象力 烂掉的代码总能抠出来 |
 | 17 binbinbbb 2022-05-02 14:46:37 +08:00 via iPhone 学习他的思路，不是广告推广。有几个修 bug 思路视频可以学习 [超强！ Java 程序员居然敢直播给 SpringBoot 找 bug ？！-哔哩哔哩] https://b23.tv/aJbsgnQ |
 | 18 1461665214 2022-05-02 15:25:15 +08:00 arthas+排除法 |
 | 19 sadfQED2 2022-05-02 17:06:44 +08:00 via Android 这能有什么方法？一点一点查呗，比如一个前端文案不对的 bug 1.检查前端展示逻辑，这个文案是哪里取值的 2.确定前端没问题，后端接口返回错误 3.抓包确定接口请求与返回，线下复现问题 4.排查代码日志，检查上下游依赖，检查代码 bug 5.上下游问题，根据 logid 串联上下游日志，进一步排查 你这折腾了一晚上都没确定问题在哪，是刚接手不懂业务逻辑和代码逻辑？就算不懂逻辑，一点一点抓包也排查出来了啊 |
 | 20 documentzhangx66 2022-05-02 19:33:58 +08:00 从工程角度来说，出现 Bug ，无非就是 2 个原因： A.设计问题：一开始的设计就是错的。 B.实现问题：在实现时出错，或者图省事没去做压力测试导致性能差，等等。 围绕这两个部分，从先易后难的思路去分析： 1.先看 2 的性能问题。从运维那里，拿到应用的 CPU 、内存、网络、存储 IO 的图表，看看有没有明显不合理的指标，比如 CPU 长时间高负载，比如存储 IO 的某个挂载点长时间的使用率（%util / 活动时间）很高，等等。 2.再看 2 的实现是否出错。此时，把日志的级别，从 INFO 或 WARNING 级别，切换到最详细的 DEBUG 级别，来分析模块与函数的调用顺序、执行时间、入参、返回结果等等，来观察与预期是否一致。 3.如果上述都没问题，就得开始检查设计问题了。这一步比较麻烦，因为需要找到比当前系统的设计者，水平更高的设计者，才能检查出问题。 |
 | 21 feller 2022-05-02 20:14:11 +08:00 这就体现了一个公司的日志平台的重要性 |
 | 22 killerv 2022-05-02 20:15:32 +08:00 主要是看日志，一定要养成日志管理的好习惯，另外排查思路也很重要。快速定位问题是个很重要的能力 |
 | 23 wintercoder 2022-05-02 21:35:59 +08:00 除了 log ，还可以靠 arthas 的 watch 功能，可以看在线每个函数的出入参 https://github.com/alibaba/arthas |
 | 24 debuginn 2022-05-02 21:53:28 +08:00 Go 的话 用 pprof 刚写了一个教程： https://www.debuginn.cn/7444.html |
 | 25 imycc 2022-05-02 22:05:07 +08:00 线上出问题，首先定位是否是由于新版本引起的，能否直接回滚（跟其他业务是否存在依赖）。 如果是内部微服务，看你们使用的框架是否提供业务间调用的监控，帮助定位到具体出问题的功能。如果是 http 服务的话就看是哪些 url 出错。 定位到具体出错的地方，接下来就得看具体问题分析了。基本手段就是查日志，看出出错的位置，再根据代码逻辑推理。 最烦人的时候日志看起来正常，有问题的地方没打日志出来，而测试环境复现不出来。这是所谓的“丢失现场”。只能把那个时段可疑的请求分个类，慢慢试了 |
 | 27 Davic1 2022-05-02 23:27:36 +08:00 楼主需要的是两个字， 冷静。 遇到紧急的问题、bug ， 先冷静。 |
 | 28 aragakiyuii 2022-05-02 23:42:37 +08:00 打日志，打 trace |
 | 29 dqzcwxb 2022-05-03 00:17:42 +08:00 java 的话用 arthas 查 |
 | 30 RedBeanIce 2022-05-03 01:22:12 +08:00 @dqzcwxb 线上一般是不可能有 arthas 的 |
| 31 RedBeanIce 2022-05-03 01:24:20 +08:00 |
 | 32 cnrting 2022-05-03 04:07:29 +08:00 via iPhone 先重启再慢慢看日志 |
 | 33 catsoul 2022-05-03 09:05:13 +08:00 找 bug 还好说，我以前遇到过一个面试问我只有一台服务器，不能停服务的情况下怎么修复线上出现的 bug... 也怪我自己学艺不精，我头都想破了也没想出办法 |
| 34 documentzhangx66 2022-05-03 11:07:54 +08:00 @catsoul 因为面试官降维打击了，这对被面试者很不公平的。 因为这玩意牵涉到系统架构、软件开发模式。 举个小例子，热修复、热插拔的系统架构，至少需要入口有负载均衡，中间的 Server 与 Client 都有对应的版本控制，后面是一堆不同版本的应用集群。哪个版本有问题，负载均衡配置一下就 OK 。而且负载均衡设备，贵的设备有冗余接口，实现双机热备，便宜的没有。这还是简单的方案，高级方案能做到王者荣耀这种 APP 都不用重启，在战斗中热修复 Bug ，这些知识面试官都不一定懂，你要懂也不会去这种小公司。 |
| 35 catsoul 2022-05-03 11:19:43 +08:00 @documentzhangx66 感谢大佬的讲解！确实有好多我完全都没有接触过的技术，感觉可以根据大佬这段话去针对性的补一波了！！ |
 | 36 xx19941215 2022-05-03 12:45:45 +08:00 一般我是看日志 |
 | 38 rb6221 2022-05-03 13:52:19 +08:00 有 log 看 log ，一定要尝试复现，复现是最重要的 你要拿到 bug 发生时的环境，服务端环境、客户端环境、前端环境，尽量模拟一下 如果不是那种报异常的 bug ，自己初步判断一下可能从哪个环节出问题，判断不了就尝试复现 修好了也要复现一下，有时候你以为的修好了并不是真的 |
| 39 dqzcwxb 2022-05-03 14:29:39 +08:00 @RedBeanIce #30 一个用来实时观察 jvm 的工具却不在实时环境使用,我没啥好说的 |
 | 40 bthulu 2022-05-04 11:15:17 +08:00 @RedBeanIce arthas 就是线上用的啊, 开发环境谁还要用 arthas 啊, IDE 断点分析不比 arthas 好用 |
 | 41 hadesqiao 2022-05-05 00:10:19 +08:00 sentry 了解一下 |
 | 42 qhkobold 2022-05-05 14:27:44 +08:00 1. 看日志，看有没有堆栈信息 2. 检查线上版本是否正确 3. 根据表象排查代码逻辑 4. 使用 arthas 等工具打印相应入参、出参等来排查定位问题 |
Select Language