故障会议分析总结

这里并不是想说关于这次会议得到的结论是什么的，问题是如何解决的，而是从更高一个层次来看待这次会议。

一开始看这个会议，各方的诉求其实是明确的：客户想要对问题的答复，以向领导、子公司领导一个交代，有交代就行；运维、开发想要在给出交代的同时，把责任给撇清楚；数据库维护事不关己高高挂起。

客户的这种对事态度，说到底还是对领导负责，而不是对事情负责。但是他的应对方法却几乎无可挑剔，值得学习。

6月13日客户端无法登录的问题，整个事故的原因是因为MQ内存爆满，导致客户端登录时无法从MQ获取消息，导致客户端无法响应。运维一开始是说客户端无法登录是程序问题，绝口不提MQ内存爆掉的事实，否认MQ爆掉与客户端无法登录之间的联系。在开发揭露出MQ与客户端无法登录之间的联系之后，尝试通过两个可能的理由想要将责任推卸到开发的身上，但是又被开发以事实反驳。90万数据才占区区2.3G内存，28万数据怎么可能消耗完毕64G内存？

这些事实反应了运维：

1、对服务器知识不足，逻辑思维能力不强，几乎没有排查故障的能力，无法完成故障排查任务和服务器维稳任务。

2、对于对自己不利的真相，不会主动透露，不会去反馈，反而尽量去掩盖。

3、善于推卸责任，在真相被揭露的情况下，想要通过各种办法将责任推到他人身上；即使无法完全推到他人身上，也至少想要拉他人下水。

4、把别人的功劳当做自己的，例如解决故障时提到“我们”，不了解情况的人咋一听好像是运维解决的。

以上是运维的固有特征，在实际工作中需要提防这一点。

客户认为，1、开发需要优化程序；2、运维在一个小时之后才发现真相，反映了运维的故障排查能力问题和应急反应能力问题；3、运维至今无法排查出为何内存会爆掉，反映了运维的故障排查能力问题。这三点，虽然认定责任大部分存在于运维，但是对运维本质上的推卸责任、隐瞒真相的本质仍然未点破。并不清楚客户是否认识到运维的本质。所以，如果不加以任何应对措施，这类事故仍然会持续发生到开发头上。

这类事故也提示了我：

1、一个事故，并非全部是一个因素、一个部门所造成的，而是可能由多个因素、多个部门共同所造成的。因而追查事故时，必须理清相关来龙去脉，对事故发生的整个过程进行正确、客观梳理，过程的每个环节的决定性因素在何处，每个环节的责任人是否有应对，是否及时应对，是否玩忽职守；当事故发生时是否有紧急预案可以启动。

2、看清楚合作部门、合作伙伴的对事态度，根据其地位、态度决定方针，如果合作伙伴的地位与自身一致，且对事态度较为懈怠，发生事故时应毫不留情地指出事实，以维护自身利益，绝不姑息。

6月16日程序包被删的问题，也反映了运维同样的问题，暂且不表。