然后，顺便打包好个人物品，抱着出去就行了！

哦哦！

上线前拜四阿哥，假期前拜佛祖，天灵灵地灵灵！

家人们，这不是危言耸听。线上无小事，开不得玩笑的啊！

还是那句话，出了问题不要慌，冷静，保持冷静。

首要记住一个原则：快速恢复。

时至如今，有一定规模的公司，后台服务状态监控各方面都做得很完善。日志系统、监控系统什么的，一般情况下，异常信息能很快速的展现在开发者眼前。

因此，赶紧马不停蹄的根据现象快速界定问题范围。然后，找到功能负责人，由负责人具体处理。毕竟没有谁比负责人更熟悉相关的业务逻辑。当然，可能你就是那个负责人，自己发现，自己解决，呕吐啊！

周知业务各个关联方：产品悉知产品状态；测试就位协助问题再现及后续验证；上一级负责人做好随时协调外部支持资源，沟通应对上层（尤为重要啊，不要试图掩盖，不声不响，消弭于无声是不可能的！）。

确定下是不是因为线上变动引起的问题，比如上线啊，配置变动，数据变动啥的。对于研发流程不甚规范的公司来说，不测试就上线，随意变动线上配置，后台修改线上数据库数据等等都是很常见的。

如果是，那么立刻做状态恢复，回滚变动。这样算是最快速高效解决办法了。也算是最容易解决的问题。

这种前提下，还有一种情况是是，因为涉及很多关联方的需求，不能回滚恢复！天啦撸，不回滚被骂死，回滚被揍死有没有。肿么办呢，还能怎么办，赶紧加补丁，快速验证快速上线修复。

如果不是变动引起的问题，那么就需要具体问题，具体分析，找问题原因了。

• 流量变大，服务能力不足了：加节点、加节点，横向扩展堆机器。

• 消息堆积，消费能力不足了：加消费者，加消费者，多张嘴就好了。

• 服务网络风暴了，抖动了：不是业务服务的问题，找 SRE，拼命催它们。大群拼命 @ 它们。

• … …

还在不是回声，是抓耳挠腮，我很无奈啊！

好吧，一套流程走起来：保留现场，查资源占用，查堆栈信息、查 gc 等等。

1、找到进程 id

jps：

ps aux | grep java

top:

2、找到线程 pid

top -Hp 进程pid

快捷键“R”进行排序，可以通过快捷键“H”查看帮助信息。

快捷键“1” 查看每个cpu使用情况：

3、查看 gc 情况

jstat -gc 进程pid

也可以加额外的参数循环输出：jstat -gc 进程pid 间隔时间 输出次数

4、线程 pid 转化为进制

printf ‘0x%x’ 线程pid

5、查看线程堆栈

jstack 进程pid | grep 转化后的线程pid

6、io 情况查看：

vmstat：

“r”：运行中；“b”：io block等待。

7、查看 jvm 信息

jinfo 进程 pid

8、old 区实例查询：

jmap -histo pid | sort -n -r -k 2 | head -10

其实最好的问题解决方法就是避免问题的出现。

不要去依赖每个人自己的自律性，也不要相信人性。有时候冷酷的规定，制度、流程反而是规避问题的最佳手段。

或许你也听过，每个看似荒唐的规定背后，都有一段不堪回首的往事。