运维KPI如何考核

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

    一直喜欢养绿萝,这种植物你只要十几天不浇水,就会枯萎。。。等到某天你又把它浇水了,你会发现,立刻就会生机盎然。。。


    在众多软件职业中,一直以为运维的KPI事最难考核的,所以也谈谈自己的理解。。。

运维KPI

    运维,常人的理解就是一个扛锅的,不停的抗锅,抗的锅也越来越大,抗的锅也越来越重,抗的锅也越来越难甩掉。。。


    造成这种窘境的原因是什么?


    运维,在传统中,痛点是啥。。。是一个成本部门,基础设施要成本,各种维护各种故障各种变更,会损害整个团队的形象,会损害整个公司的利益,会损害整个公司的社会形象。。。


    关键时刻掉链子,出了故障不能及时解决,没出故障的时候天天在那闲着。。。


    如何改善这种窘境。。。实施落地难度极大,相当大,非常大。。。


    回忆总想哭。。。回忆总是像耳光,一巴掌一巴掌打在脸上,疼不疼。。。多回忆几次就好了,慢慢。。。就不疼了,哈哈


    各种HRSB部门总是认为运维部门和其他部门,也可以按照一般的考核来进行考核,但是运维的工作性质却不一样,所以呢,运维也是最难考核的一种。。。


    考核运维那么难,那么可以将运维和研发进行收编统一管理,从而发展出了SRE这个职业。。。


    为什么SRE这个职业不能单纯的成本部门?


    SRE主要的关注点在于可靠性,也就是一个软件能持续运行的时间,时间越长越好。。。Emmm,持久性?


    关注可靠性,从而会有很多创造性的举动,而不是被动的进行运维,被动的进行处理问题,被动的进行各种策略的调整。。。


    SRE可以化身为研发,研发也能转变成SRE,因为是使用软件研发的观点来进行运维,这样两者的目标是同一的,也就是都是为了可靠性,从而可以大大节省开发和运维的沟通时间,磨合是为了更好的沟通。。。内耗了解一下,开发骂运维傻逼,运维骂傻逼。。。


    跟聪明人说话,一句话我们就懂即将要做什么,未来会如何发展,以后我们如何改进。。。跟傻逼说话,拉低整个人的智商,降低整个人的身价。。。


    SRE如何从成本消耗部门转变为生产部门的?


    能开发出更好的系统来辅助配合业务系统,例如监控系统,定制化的监控;搭建更好的系统来优化目前的系统,延迟优化等,从而节省成本。。。


    其实最主要的东西,就是运维的关注点发生改变,原来你可能每天处理各种工单,处理各种告警,处理各种故障,处理各种变更,那又如何?。。。凌晨四点的太阳应该经常看到吧。。。


    从各种杂乱的琐事,屁事,破事里面抽身出来,关注可靠性,其实挺难的。。。因为太多的琐事来进行中断,一个中断就要进行上下文切换,就要陷入到内核,开销太大了。。。


    纵观每天的每件事,我们都是为了保证可靠性。。。变更审核的流程越来越长,故障处理的时间越来越少,告警处理的越来越及时,这些策略,充其量就是保护运维的一种方式。。。但是对于运维来说,这种精神压力也是越来越重的,垃圾系统越来越多,呈现出失控的状态。。。


    关注可靠性,从而可以把精力从人的身上拉回到系统中。。。所谓的铁打的营盘,流水的兵。。。其实这种转变也很难,毕竟百分之九十的运维没有开发经验。。。


    以前一直关注人,核心的人,最关键的人,然而,并没有什么卵用,太依赖了,想去除这种依赖,那么只能打造更加强大的系统,从而SRE可以在当前的系统上进行越来越多的改善,构造自动化系统,打造可靠性越来越强的系统。。。人员流失?无所谓,因为系统本来就很可靠,少了谁,来了谁,可靠性都在这里摆放着。。。


    纵观所有的KPI,考核来考核去,莫不是为了业务更好的发展,命运之轮的演练。。。


    用上班时间考核?不合适,有的时候躺在床上也是在处理问题。。。用处理的工单数来考核?不合适,工单数量太多只能说明系统太难用。。。用处理的告警,故障数量来衡量?不合适,这种只能说明系统是一个不可运维的系统


    考核的要点,能为系统增加多少可靠性,那么KPI就怎么打!!!其实这个也很难,非常难,相当难。。。


    SRE开发了一个系统,增加了系统自动化的程度,KPI优秀。。。SRE处理了一个故障,发现了系统的一个BUG,推广到所有的系统,反馈经验给研发部门,彻底修复BUG,KPI优秀。。。总体的宗旨就是:提高了系统的可靠性,那就是优秀。。。


    如果我不会开发,我怎么提高我的KPI,如何到达优秀?


    配合研发提高系统的可靠性。。。可以观察监控系统的性能,进行分析,提供相关的数据给研发,从而进行改进,例如观察各种慢SQL,研发进行修改优化。。。可以观察监控系统的告警数量,反馈给研发,进行改进,从而减少系统告警的数量。。。可以观察监控系统的流量,时间延迟,反馈给研发,预测未来流量,是否要进行扩容,是否要进行优化系统。。。


    命运之轮的演练,发现系统的问题,打造运维宝典,提高系统的可靠性。。。第一次演练,所用时长,出现的问题,改进。。。第二次演练,换一种方式,所用的时间,出现的问题,改进。。。第三次演练,换一个团队,所用的时间,出现的问题,改进。。。随时准备,提高警觉性,掌控服务的状态,掌握系统的可靠性。。。


    运维的KPI的出现,是为了打造一个可靠性达到预期的系统;运维的KPI出现,是为了打造一支强力之兵。。。以战养战,还是休养生息?


    其实如果运维是一个成本消耗部门,还有一个非常尴尬的事儿,就是随着时间,每个人的能力都有所增长,换句话说,每个人的工资也要增长,一个成本消耗部门,成本越来越高。。。这也就是为啥要裁人换血的原因。。。为应对这种情况,只能是运维的人员数量不随着系统,不随着变更,不随着琐事的增多而线性增多。。。所以SRE的出现,也会解决这种问题,打造的自动化程度越来越高,能处理的问题,能接手的系统,成本都在预期范围之内。


    考核运维考勤的KPI,都是傻逼制定的,这种傻逼一定要怼,怼到死。。。嗯。。。最终受伤害的只会是自己,但是不伤害一下,怎么成长,怎么见识一下人生的套路。。。


风言风语

     想上九天星摘月,想去五湖四海烤鱼。。。


    人世间,走过最多的路,就是人间的套路。。。

640?wx_fmt=jpeg

    谁在抹杀我的激情,谁又在召唤我的战魂。。。在回眸之间,需要一场打击,唤醒挑战之魂。。。


    人生最大的沟壑就是,从理论过渡到实践,再从实践回归理论。。。脑瓜嗡嗡作响,都是水的声音。。。。不要惹我。。。要不然,我脑子里面倒出来的水都能淹死你们。。。

    

猜你喜欢

转载自blog.csdn.net/TM6zNf87MDG7Bo/article/details/85219903