运维人必备的高级生存指南，甩锅姿势更优雅？
1、故障，故障，还是故障
任何一个故障发生时，没有任何一个人是无辜的，开发的责任在于代码的bug，测试的责任在于测试用例不健全，运维的责任在于监控不到位或者故障处理不给力，一般在故障定责中，声音越大的一方，往往责任越大，所以在故障定责时，要学会察言观色，选择主攻点，不要广撒网，到处开炮。
首先，故障并非都是坏事，偶尔它是避免大故障发生的预警。
其次故障责任遵循是否引起还有是否有能力去改变两个方面制定，责权一定要统一。
再次大故障尽量减少责任，小故障尽量增加责任，漏漏脸也好。
最后，老祖宗的名言，福兮祸所伏，祸兮福所倚，吃亏是福。
2、定责时一些方法和话术技巧
1）言多必失
定责时，一定要少说话，简洁，说话时要去抓住对方的漏洞，尤其是逻辑漏洞，尤其是攻击对方的前提假设。
例如：
“你说的太理想化了，我们实际情况是，……”
“你这个太不专业了，怎么可以这样去做假设……”
同时，只阐述事实，并且和故障相关，注意，不要用过多的主观词语字眼
我觉得，我认为，我想这些都要少用甚至不用，我一般用的最多的字眼是“咱们，我们”。比如一句话：
“我觉得，这次故障测试方出现了漏测的情况，是主因”，
这样说就很不好，好的说法是，“大家想法都是好的，咱们先搁置争议，静下来想一想，如果测试到位，是否这次故障就可以避免？”
2）找好自己的盟友
故障时，往往是三国混战或者多国混战，这时候要打一方，拉一方。
例如，拉开发，打测试，“大家有些搞混了，我们首先要找的是问题根源是什么，是代码bug啊”
再例如，拉测试，打开发，“细想想，测试同学也是很为难的，咱们生产环境那么复杂，开发要保证第一道关的”
或者释放善意，等着被拉
例如，“这次监控做的很到位，大大减少了故障的定位时间”
3）情感公式，站在道德制高点
这是一个屡试不爽的方法
例如：
“你考虑问题太狭窄了，应该站在公司的层面去考虑”
“现在还没到那个阶段，不要回答how，要问一下why”
“如果我来承担责任，没有问题，但真的解决问题了么，下次不会重复发生了么？”
“我当然知道公司的实际是什么，但我们不是应该朝对的方向前进么？”
可以主动示弱：
4）不要直接回答问题，记住，不要直接回答问题
不直接回答问题的好处有二，其一，显得高级，其二，给自己留出思考空间
方法一、反复对不起
“对不起，你说的我不太明白，能再说一遍么？”
“对不起，我不太清楚，了解一下再答复你？”
“对不起，刚才走神了，能再说一遍么？”
这种方法尤其适合一个新员工参加故障讨论会
方法二、提问
“你说的我没法直接回答你，不过，我想问一下，你觉得你们团队问题在哪里？”
“等一等，有个问题，我不理解，你刚才所说的前提是什么？”
方法三、重复或者翻译别人的话，注意重复语气要慢，有明显漏洞的地方，要更慢
“刚才说的话，我是不是可以这样理解，……”
5）说不通，那就换一种方式
方法一、直接说结论
“ok，各位说的都有道理，结论是不是这样？”
方法二、迂回反复
“这个故障的确我这里有做的不好的地方，但是就算我改进了，大家想一下，这个故障就能避免了么？”
方法三、拉人下水，有锅一起背
“我再思考另外一个问题，除了大家说的之外，还有哪些我们能做的更好的呢？”
方法四、和事佬（一般到和事佬时，基本上就赢了）
“二位说的都有道理，的确各个团队都有做的不好的地方，大家觉得呢？”
6）千万不要挑战别人的专业，也不要陷进别的专业
如果我们要想打败泰森，肯定不是和他上擂台，而是要和他比说中国话。
“我承认你的领域我不太理解，但故障处理是一个软件工程，从软件工程角度来看，应该是……”
“好，其实这里存在一个问题，那就是，监控是万能的么？或者说，为什么监控做不到万能的？”
7）最后几点
首先，千万不要急，不要急，不要急，一急你就输了 其次，角度一定要新，不要说别人都知道的事
再次，任何人说的每一句话，都要打一个问号，不要轻易接受
最后，故障无小事，做好充足准备，甚至有谁会参加，他们什么背景和性格都要了解清楚。
运维是一个很难说清的事情，因为太杂，太广，别人很可能一句，我觉得是网络的问题，就让你忙活大半天，所以运维人员一定要学会保护自己，锅，该背的背，不能背的一定不背。
END
官方站点：www.linuxprobe.com
Linux命令大全：www.linuxcool.com
刘遄老师QQ：5604215
Linux技术交流群：2636170
（新群，火热加群中……）
想要学习Linux系统的读者可以点击"阅读原文"按钮来了解书籍《Linux就该这么学》，同时也非常适合专业的运维人员阅读，成为辅助您工作的高价值工具书！
微信扫码关注该文公众号作者