运维甩锅高级指南

编程三分钟

共 2506字,需浏览 6分钟

 ·

2024-04-10 15:46

f2ab797e0eeb279bde6c34150bb41f58.webp 436b5e8037d41d4712832681745158fd.webp

点击上方蓝字关注我们

d586814f652f2858a36a8cb906ca1e74.webp


大家好,我是熊哥。首先声明,本文章只在针对故障中那些不愿承担责任,而把锅甩给运维部门的人,如果讨论故障的都是君子,那么本文并不建议使用,切记。

e35783584bbcd30c5cbcbb0bea74a21c.webp

1,故障,故障,还是故障


任何一个故障发生时,没有任何一个人是无辜的,开发的责任在于代码的bug,测试的责任在于测试用例不健全,运维的责任在于监控不到位或者故障处理不给力,一般在故障定责中,声音越大的一方,往往责任越大,所以在故障定责时,要学会察言观色,选择主攻点,不要广撒网,到处开炮。

关于故障处理和故障定责,这不是体现个人责任心和担当的场所,一定要分清哪些是自己的主职,哪些自己在协助帮忙,把故障一股脑揽在自己身上,好一点的人会一时感激,但最后为了去掉不亏欠感以达到内心的最终平和,就会找一大堆理由证明责任真的是你的,不巧的是,这些理由,一找一大把,因为雪崩时,的确没有一片雪花是无辜的。


所以,故障定责应该遵循以下几个原则:

1),首先,故障并非都是坏事,偶尔它是避免大故障发生的预警。

2),其次故障责任遵循是否引起还有是否有能力去改变两个方面制定,责权一定要统一。

3),再次大故障尽量减少责任,小故障尽量增加责任,漏漏脸也好。

4),最后,老祖宗的名言,福兮祸所伏,祸兮福所倚,吃亏是福。


a2ec0aec0f6bf2e79a01ce396f5cd7f7.webp


2,定责时一些方法和话术技巧

再次强调一遍,下面内容只防小人,不防君子,不主动欺负人,但别人欺负我,不行


1),言多必失

定责时,一定要少说话,简洁,说话时要去抓住对方的漏洞,尤其是逻辑漏洞,尤其是攻击对方的前提假设。

例如:

“你说的太理想化了,我们实际情况是,……”

“你这个太不专业了,怎么可以这样去做假设……”

同时,只阐述事实,并且和故障相关,注意,不要用过多的主观词语字眼

“我觉得,我认为,我想”这些都要少用甚至不用,我一般用的最多的字眼是“咱们,我们”。

比如一句话:

“我觉得,这次故障测试方出现了漏测的情况,是主因”,这样说就很不好,好的说法是,“大家想法都是好的,咱们先搁置争议,静下来想一想,如果测试到位,是否这次故障就可以避免?”


2),找好自己的盟友

故障时,往往是三国混战或者多国混战,这时候要打一方,拉一方。

例如,拉开发,打测试,“大家有些搞混了,我们首先要找的是问题根源是什么,是代码bug啊”

再例如,拉测试,打开发,“细想想,测试同学也是很为难的,咱们生产环境那么复杂,开发要保证第一道关的”

或者释放善意,等着被拉

例如,“这次监控做的很到位,大大减少了故障的定位时间


3),情感公式,站在道德制高点

这是一个屡试不爽的方法

例如:

“你考虑问题太狭窄了,应该站在公司的层面去考虑”

“现在还没到那个阶段,不要回答how,要问一下why”

如果我来承担责任,没有问题,但真的解决问题了么,下次不会重复发生了么?

“我当然知道公司的实际是什么,但我们不是应该朝对的方向前进么?”

可以主动示弱:

有些故障,运维也背了,例如xxx,但现在看起来,效果并不好,团结是有了,然而没有真正解决问题

为了做这个变更,我已经特意选择凌晨去做,已经熬了好几个通宵了


4),不要直接回答问题,记住,不要直接回答问题

不直接回答问题的好处有二,其一,显得高级,其二,给自己留出思考空间

方法一,反复对不起

“对不起,你说的我不太明白,能再说一遍么?”

“对不起,我不太清楚,了解一下再答复你?”

“对不起,刚才走神了,能再说一遍么?”

这种方法尤其适合一个新员工参加故障讨论会

方法二,提问

“你说的我没法直接回答你,不过,我想问一下,你觉得你们团队问题在哪里?”

“等一等,有个问题,我不理解,你刚才所说的前提是什么?”

方法三,重复或者翻译别人的话,注意重复语气要慢,有明显漏洞的地方,要更慢

刚才说的话,我是不是可以这样理解,……

4a24c5b2a942323072b131528e8baa83.webp


5),说不通,那就换一种方式

方法一,直接说结论

“ok,各位说的都有道理,结论是不是这样?”

方法二,迂回反复

“这个故障的确我这里有做的不好的地方,但是就算我改进了,大家想一下,这个故障就能避免了么?”

方法三,拉人下水,有锅一起背

“我再思考另外一个问题,除了大家说的之外,还有哪些我们能做的更好的呢?”

方法四,和事佬(一般到和事佬时,基本上就赢了)

二位说的都有道理,的确各个团队都有做的不好的地方,大家觉得呢?


6),千万不要挑战别人的专业,也不要陷进别的专业

如果我们要想打败泰森,肯定不是和他上擂台,而是要和他比说中国话。

“我承认你的领域我不太理解,但故障处理是一个软件工程,从软件工程角度来看,应该是……”

好,其实这里存在一个问题,那就是,监控是万能的么?或者说,为什么监控做不到万能的?”


7),最后几点

首先,千万不要急,不要急,不要急,一急你就输了

其次,角度一定要新,不要说别人都知道的事

再次,任何人说的每一句话,都要打一个问号,不要轻易接受

最后,故障无小事,做好充足准备,甚至有谁会参加,他们什么背景和性格都要了解清楚。


运维是一个很难说清的事情,因为太杂,太广,别人很可能一句,我觉得是网络的问题,就让你忙活大半天,所以运维人员一定要学会保护自己,锅,该背的背,不能背的一定不背。


往期推荐

明明大厂都在裁员,为什么运维还是这么难招?

2024字节跳动薪资改革,利好普通人入职?

我发现很多人对SRE工作有误解,很简单吗?

AiOps智能运维技术领域2024年发展预测

SRE学习路线图出炉

049511295557a2fa6ed34c384c2620ba.webp

点击下方“阅读原文”查看 SRE学习路线图

浏览 23
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报