一次生产环境P0级事故分析( 五 ) _P0级事故

为什么控制台刷日志会造成CPU异常
但是最关键的问题来了，为什么控制台刷日志会造成CPU异常，这个也是阻碍我们排查问题的最大原因，我们也在自己笔记本上做了大量模拟，包括通过JMeter做压测，都没发现控制台刷日志会造成CPU异常。
其实解决过程很简单，关闭debug日志，系统基本就是正常了，但是本着刨根究底的态度，这个问题卡在这里很难受，这类问题也就独此一家吧。
因为那天甲方人也在，硬件公司也来了，聊天的过程中终于发现了问题所在。

文章插图

你看的没错，运行了系统这么久的服务器居然是两台VM虚拟机。
用过虚拟机的都知道，虚拟机是公用主机的内存和CPU，是通过动态计算分配出来的，经过和专业人士交流以后，虚拟机内部很多操作都是通过软件模拟出来的，比如网络。这也解释了9.21号服务器CPU异常以后，造成网络大面积延迟。
大概的过程基本就是CMD封装刷日志-->CPU异常-->进而挂起了其他所有操作(包括网络等)，等待CMD日志刷完，释放CPU以后，又恢复正常了。

因为对操作系统原理其实不是特别了解，所以也一直分析不到到底是什么情况，到时cmd刷日志占用了所有的CPU，也不给我们权限去查看VM服务端相关的日志，这个属于硬件公司管辖范围

硬件公司死活不承认VM虚拟化做服务器是有问题的，但是从我的角度看，单单就是CPU飙高，网络会出现大面积延迟就是有问题的。可能硬件公司知道猫腻吧，所以也不给我们看服务端日志，他们一直强调服务器是没问题的。

前面也讲到，回公司以后，我们搭建过一套一模一样的环境(实体机)，就是怎么也复现不了控制台疯狂刷日志，造成CPU异常，系统假死的情况。

总结
人的习惯就是这样，第一印象把问题都会甩给“异常输出的平台”，所以这个事件基本上由我们软件平台全部背锅了，我们事后还写了很大一份“事故总结报告”，各种“保证书”等等。
事件总结

工艺流程不规范，有现场操作的工艺流程，比如在不该操作的时候进行操作；质量管理流程不规范，比如代码审计不足，环境模拟不充分(模糊查询问题，公司只有几千条数据)，公司没有搭建负载均衡环境测试等等；分析设计不充分，比如模糊查询的问题。
老系统日志系统比较欠缺，很多问题都是靠人工查看控制台或者翻阅本地log4j日志，也浪费了大量的时间。
突发危机处理能力不够，比如当时多等待10分钟就没问题了，单台服务器其实可以使用的(那时候已经没有登录场景了，都已经登录过了)等等。那时候很多人堆在一起，闹哄哄七嘴八舌的，也没有冷静下来思考，导致事态严重化了。
应急方案没有，系统挂了就没有第二套方案去应急。

这是一次典型事件，碰到了我职业生涯没碰到过的异常，又积累了一笔经验。