一次p3故障总结（沟通及流程篇）

这几天组内接连发生一个p0故障，一个p3故障。
p0就是上一篇波哥说的那个ETCD扩容导致整个业务不可用，我在产房门口坐地上处理的那次。
今天又发生了一次p3级别故障。
起因是研发侧同学说一台机器时不时就hang住，无法登录和执行任何命令。
系统组同学排查发现问题机是个虚拟机，继而发现同宿主机上的其他虚拟机都有这个问题。
联系机房人员帮忙查看所在的物理机告警指示灯是否有亮起，答复是没有。
服务器运行将近1500多天了。
物理机时不时hang住也没办法热迁移上面的虚拟机。
hang住过程期间ping正常，说明不是网络异常出现的假死。
以上交代清楚了本次问题的前提。

由于基础系统组不在我这边业务范畴，所以本次问题属于友情支援。
由于宿主机上面的虚拟机不止一个，大概七八个左右，系统侧同事给出的处理意见是断电重启一下。
因为业务侧第一次提交问题是给了我们，所以波哥友情帮忙组织，处理流程是这样的。
拉群把所有虚拟机相关业务侧人员拉到一起。告知情况，并希望业务侧予以确认是否可以重启，什么时间重启以及重启之后的风险（有可能起不来）。
这一切都交给了组内新来的实习生来做，但是他没有完美的传达明白我的意思，波哥只好再次解释清楚。

很明显，实习生涉世未深，这句话问出来好多漏洞，好像有问题就必须重启解决么?虽然指定了列表但描述是几台这个非常模糊，有歧义?另外让人家评估什么没说清楚!

那么我只好接过话来。。。

沟通一定要简单直接明确。

第一告知风险，第二让对方明确是否可以操作。

业务侧也是老程序员，他的质疑也是简单直接。

其实后面不应该我接话了，应该系统组同事来回答，说白了就是告知对方最坏的情况的应急方案是什么。

但是系统侧并没有接，系统侧虽然不是波哥管辖范围，但也是基础服务组的，都是一个弹坑的兄弟，所以波哥只能继续让沟通主题明确一些，到底能不能重启?服务是否有集群冗余?

要是没有冗余，那么需要什么环境你提出来让系统侧准备好。并且口头询问系统侧初始化虚拟机要多长时间。答十分钟左右。

业务侧回话，需要拉更多的人来确认业务，在现有机器上把脚本备份下来。

至此沟通完成，业务侧开始拉人进群各种确认，系统侧联系机房准备。

让沟通更具体，注意力聚焦在双方能看懂并且范围明确的问题上。

其实这样这种问法就比较鸡贼了！正常情况其实不至于这样。

业务侧如果回答能重启，那这边就执行，如果因为处理出问题影响业务了，可以解释为业务侧评估过说的可以操作。

要说不能，那就不处理，如果因为没处理而出了问题也可以说业务侧不让处理。

但是业务这种确认和备份是需要时间的，系统侧同事就有些不耐烦了！一个重启机器至于吗？又没有硬件告警。

其实我也或多或少感受到了！那么在接下来的沟通组织我便退出了！不再干预。毕竟不在自己管辖范围，不好左右主流程。

整个业务确认时间大概持续1个半小时左右。业务侧反馈可以操作了！

系统侧开始执行重启动作!~

悲剧如期而至！

不过好在前期都有打过预防针，不至于特别慌乱!

这里波哥不是显摆或者怎样，波哥已经过了那个年纪和劲头。也没有必要搞哪些!

而且这些按流程办事的思路和交流沟通技巧也是我认为基础运维应该具备的基本条件，也不是吹嘘的资本。

并且我也没有避免悲剧的发生，就结果言其实我做的也都是无用功，是失败的。

其实有太多的故障都是我们不是按规矩办事，甚至连基本的告知义务都没有，对于其他同事的感知就是忽然就不好使了！要么就是没有认真对待和处理、备用应急方案的不足等等人为因素导致的。

一定要把工作做到前期，慢点都没关系!

事后真出问题，不要抵赖，不要找借口，是你的责任就承担，并且需要第一时间说明，不是你的坚决不认。

模棱两可责任不清楚的，你自己要想清楚，说清楚。这一块灰色就是发挥职场智慧的空间，波哥一般是看对方什么态度，要是推诿、不屑、甩锅的那必须力战到底，多年的专业知识都会成为持续输出的伤害。

对方和和气气，认认真真找问题的，那就一起坐下来看日志，对操作、找监控、做测试、找问题。一般静下心来看问题，找到根因不会超过两天!~并且以后绝对会避免，成为双方的职场经验。这是最好的结果。

一切技术问题和故障都是小问题，终究会过去，不要害怕和担心!

耐心一点，细心一些才能少背锅。多找找自己的原因，技术、沟通、思维模式、还是人际关系？到底哪方面出了问题。这次错了，下次换个方法处理试试呗！

干不好，老是接锅、老觉得自己受委屈，90%是自己的原因，亦或者99%吧！

小结:

1、告知义务，话一定要说清楚，明确问题，对方明确答复。

2、应急预案，风险评估，提前做好包括但不限于备份，迁移、人员、设备的备份等等。

3、技术实力，操作流程和方法选择。

4、事后分析总结的能力。