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