确定挂机 络绎不绝的来不同类型的bug
当bug滚滚而来时，不要怀疑，你的发布的应用基本是不可用状态了。
观察哨兵监控数据，特别是内存打到80%基本就挂机了，或者监控数据缺失也基本是挂机了。
此时应当马上决断：
通知运营暂停操作(大多数是因为后台应用导致的，纯经验猜测，因为你也不可能让外部用户停止操作)
重启大多数机器，保留一台机器保存现场(下线机器)。
实例：
友品app首页有频率的失败
运营提bug，后台导出每次都不可用，其他的偶现不可用
找到原因 把此问题复现出来
根据各方面的反馈，加自身的迭代，找寻线索，积极在预发尝试，以求确定病根。
最近上线内容
最近使用操作
最近超时接口
实例：
见上描述，导出每次不可用，马上在预发复现此问题。
感谢运营的反馈，此处可总结，运营在使用系统过程中出现问题要及时反馈，不要害羞。
确定问题根源
线上一般内存偏大，有6-8G，用jmap下来文件很大，也不易分析。
此时可转换思路，创建一个干净的环境，调试此固定逻辑。
这里的问题是线上数据怎么来？
dubbo 直连(不建议)
通知运维导出线上数据
搭建本地环境，调试固定逻辑：
相关业务逻辑迁移到本地(线上数据来源是2，此时需要导入数据，封装dao)
本地设置 -xms-xmx为20M(设置本地使用内存)
jmap -histo 77710 >./Downloads/15.log 导出内存文件查看内存消耗
分析并解决，如果是自己责任内则解决，否则抛出(纯能力和经验)
实例：
在本地环境调试后发现导出正常，20M内存可以支撑导出37万条数据没有问题。
此时回过头去看线上逻辑代码，比本地多一个文件加水印，此时修改代码，再文件生成后打印一条日志，部署预发。
发现文件可以生成，但文件加水印迟迟未结束。
去掉文件加水印后部署预发，导出正常。
此时排查出问题出在文件加水印，此为中间件的工具，故而不做解决，直接去掉加水印提测。并报告问题给相应人。
总结
判断是否挂机
通知运营暂停操作
重启大多数机器，保留一台机器保存现场
找到那个操作引起的此现象
转为本地调试，找寻问题根源
解决或抛出
408
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
