然后，顺便打包好个人物品，抱着出去就行了！
哦哦！
(资料图片)
上线前拜四阿哥，假期前拜佛祖，天灵灵地灵灵！
家人们，这不是危言耸听。线上无小事，开不得玩笑的啊！
一、快速恢复还是那句话，出了问题不要慌，冷静，保持冷静。
首要记住一个原则：快速恢复。
时至如今，有一定规模的公司，后台服务状态监控各方面都做得很完善。日志系统、监控系统什么的，一般情况下，异常信息能很快速的展现在开发者眼前。
因此，赶紧马不停蹄的根据现象快速界定问题范围。然后，找到功能负责人，由负责人具体处理。毕竟没有谁比负责人更熟悉相关的业务逻辑。当然，可能你就是那个负责人，自己发现，自己解决，呕吐啊！
周知业务各个关联方：产品悉知产品状态；测试就位协助问题再现及后续验证；上一级负责人做好随时协调外部支持资源，沟通应对上层（尤为重要啊，不要试图掩盖，不声不响，消弭于无声是不可能的！）。
确定下是不是因为线上变动引起的问题，比如上线啊，配置变动，数据变动啥的。对于研发流程不甚规范的公司来说，不测试就上线，随意变动线上配置，后台修改线上数据库数据等等都是很常见的。
如果是，那么立刻做状态恢复，回滚变动。这样算是最快速高效解决办法了。也算是最容易解决的问题。
这种前提下，还有一种情况是是，因为涉及很多关联方的需求，不能回滚恢复！天啦撸，不回滚被骂死，回滚被揍死有没有。肿么办呢，还能怎么办，赶紧加补丁，快速验证快速上线修复。
如果不是变动引起的问题，那么就需要具体问题，具体分析，找问题原因了。
流量变大，服务能力不足了：加节点、加节点，横向扩展堆机器。
消息堆积，消费能力不足了：加消费者，加消费者，多张嘴就好了。
服务网络风暴了，抖动了：不是业务服务的问题，找 SRE，拼命催它们。大群拼命 @ 它们。
... ...
二、问题定位上面所说的快速恢复都是针对能够快速界定问题原因的情景。但是，很多时候你会发现，那些原因都排除了，问题还在，还在。还在不是回声，是抓耳挠腮，我很无奈啊！
好吧，一套流程走起来：保留现场，查资源占用，查堆栈信息、查 gc 等等。
1、找到进程 idjps：
ps aux | grep java
top:
2、找到线程 pidtop -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
三、关于研发流程其实最好的问题解决方法就是避免问题的出现。
不要去依赖每个人自己的自律性，也不要相信人性。有时候冷酷的规定，制度、流程反而是规避问题的最佳手段。
或许你也听过，每个看似荒唐的规定背后，都有一段不堪回首的往事。
标签：
