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

也不一定要按照我的问题提出解决方法，也可以是各位在工作中总结出来的好的解决方案

看日志呗

可以从函数设计入手

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

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

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

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

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

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

不打 log 的?

主要靠 log

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

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

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

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

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

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

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

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

看日志

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

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

先回滚, 回头再找

二分查找法 + 想象力

烂掉的代码总能抠出来

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

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

arthas+排除法

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

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

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

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

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

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

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

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

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

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

这就体现了一个公司的日志平台的重要性

主要是看日志，一定要养成日志管理的好习惯，另外排查思路也很重要。快速定位问题是个很重要的能力

除了 log ，还可以靠 arthas 的 watch 功能，可以看在线每个函数的出入参 github.com/alibaba/arthas

Go 的话 用 pprof 刚写了一个教程： www.debuginn.cn/7444.html

线上出问题，首先定位是否是由于新版本引起的，能否直接回滚（跟其他业务是否存在依赖）。
如果是内部微服务，看你们使用的框架是否提供业务间调用的监控，帮助定位到具体出问题的功能。如果是 http 服务的话就看是哪些 url 出错。
定位到具体出错的地方，接下来就得看具体问题分析了。基本手段就是查日志，看出出错的位置，再根据代码逻辑推理。
最烦人的时候日志看起来正常，有问题的地方没打日志出来，而测试环境复现不出来。这是所谓的“丢失现场”。只能把那个时段可疑的请求分个类，慢慢试了

＃22 我觉得我的快速定位问题能力就不太行，遇到问题手忙脚乱

楼主需要的是两个字， 冷静。 遇到紧急的问题、bug ， 先冷静。

打日志，打 trace

java 的话用 arthas 查

线上一般是不可能有 arthas 的

+1

看看链路日志，或者入参，一行行代码走查吧，，没什么好的办法

楼上说的 arthas ，线上环境一般不可能有吧

先重启再慢慢看日志🐶

找 bug 还好说，我以前遇到过一个面试问我只有一台服务器，不能停服务的情况下怎么修复线上出现的 bug...

也怪我自己学艺不精，我头都想破了也没想出办法

因为面试官降维打击了，这对被面试者很不公平的。

因为这玩意牵涉到系统架构、软件开发模式。

举个小例子，热修复、热插拔的系统架构，至少需要入口有负载均衡，中间的 Server 与 Client 都有对应的版本控制，后面是一堆不同版本的应用集群。哪个版本有问题，负载均衡配置一下就 OK 。而且负载均衡设备，贵的设备有冗余接口，实现双机热备，便宜的没有。这还是简单的方案，高级方案能做到王者荣耀这种 APP 都不用重启，在战斗中热修复 Bug ，这些知识面试官都不一定懂，你要懂也不会去这种小公司。

感谢大佬的讲解！确实有好多我完全都没有接触过的技术，感觉可以根据大佬这段话去针对性的补一波了！！

一般我是看日志

主要是得练，这就是经验的重要性；我觉得你可以针对性的搞一些故障演练

有 log 看 log ，一定要尝试复现，复现是最重要的
你要拿到 bug 发生时的环境，服务端环境、客户端环境、前端环境，尽量模拟一下
如果不是那种报异常的 bug ，自己初步判断一下可能从哪个环节出问题，判断不了就尝试复现
修好了也要复现一下，有时候你以为的修好了并不是真的

＃30 一个用来实时观察 jvm 的工具却不在实时环境使用,我没啥好说的

arthas 就是线上用的啊, 开发环境谁还要用 arthas 啊, IDE 断点分析不比 arthas 好用

sentry 了解一下