运维抗锅?

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/80212839
序言

   天将降大锅于斯人也必先苦其心志,劳其体肤,饿其筋骨。。。。


    这就是抗锅的理由?这就是你一天不吃饭,然后去抗锅的理由?。。。嗯。。。是的。


处理过程解析

   中午躺在床上,思考人生。。。忽北风来。。。。短信像疯了一样,大量告警,各种port down,看告警好像是虚拟机挂了,云,不怂。。。平台会自动进行迁移,三分钟过后,告警短信没有了,还以为是恢复了。。。没太在意,让人登录监控平台看看是不是物理机宕机,追查下原因就好了。。。登录发现。。监控平台也挂了,ping,DNS可以解析。。。那么。。。问题好像很严重了,穿上衣服去抗锅。。。。问题处理的动作就是。。没有重启是解决不了的。。。


    不准备对故障进行过多的描述,只是反思这种情况的处理策略:

    1、 云,一朵又一朵,监控平台也放在云里面,那么如果整朵云都挂了,全挂。。。全部挂,那么监控平台不放在云外。如果监控平台是最主要的监控手段,所有的信息例如CMDB信息都在监控平台中,那么就有强烈的欲望把监控平台独立于云平台。作为掌控者,作为指挥中心,应该单独建立,不应该和士兵一起死掉,狡兔三窟。。。


    2、 恢复业务为第一要务,不要相信所谓的研发,不要相信所谓的产品,都是TM的XX,总是按照固定思维走,整个业务全部停止了,还TM去慢慢查,查你妹啊,先找到故障点,迅速定位,该TM重启重启,别TM想着这个服务那个服务的依赖,依赖可以慢慢接,就算是部分服务恢复也是先抢救回来再说。。。排查问题的思路很重要。。。


    3、 上来就是甩锅,是因为锅太黑么?总在江湖漂,谁人不背锅。。。不去追查本质原因,上来就甩锅,一群怂逼。。。背个锅算什么,莫名其妙的锅。。这种锅我不背。。。背不动。。。。有技术含量的锅背的舒服,有成就感,背了一个锅,能促进产品更加稳定,更加可靠,性能更好,这个锅我能背一百个。。。。能不能有点原则,别人抗了锅就能没事了?团队死一个同伴,就舒服了?到底TM的是做产品还是TM让队友猜坑?劳资保你周全,你反手一刀,把我杀了。。。


    4、 本质问题,故障的根本原因在哪里?如何改进?下一步的动作是什么?如何避免?如何预防?不追查本质原因,这种原则就应该是产品红线,谁碰谁死。。。你不追查,那就直接干掉,不符合产品构造思维。。。FUCK YOU。。。不支援队友的都得死。。。一问根本原因的进度,分析中。。。过一个小时问下,分析中。。。。过五个小时问下,分析中。。。分析你妹。。。


闲扯

  谈笑间,灰飞烟灭。。。


    谈笑间,故障就处理了,只要告知这个故障就可以了。。。大大小小的故障都要亲自处理,简直是FUCK了,养兵千日,自己上。。。心塞。。。


    说好的有我和没我是一样的。。。为何不是我所想的这样。。。。


    话说,无论多牛逼的技术,不是看一眼就懂了么,为啥别人看我操作那么多次还不能领会?是因为这其中有很大的技巧?然而。。。并没有啊。。。那么!!!为什么看不懂,是眼瞎还是懒得看?。。。WHY?


    SLB。。。名副其实,leader SB。。。。这个挂了,全部都挂了,回天乏力,再牛逼的产品,也要走这个。。。


    如何在有限的资源下做更多的事?。。。这只不过是一种权衡。。。。这也只不过是一种战略。。。。想做,就不是浪费时间。。。


    抗锅是艺术。。。抗锅是责任。。。那么用什么姿势抗锅更加帅?


    夏天了,温度上升了,服务器都在躁动,今天宕机,明天内存溢出。。。。蚊子多了,服务器也有点扛不住了。。。


    HP的服务器质量就是好,每次重启下就好啦。


640?wx_fmt=png

    猜猜这个图是啥意思。。。。

没有更多推荐了,返回首页