运维抗锅？

序言

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

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

处理过程解析

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

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

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

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

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

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

闲扯

  谈笑间，灰飞烟灭。。。

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

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

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

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

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

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

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

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

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