运维KPI如何考核

Posted 2023-03-04 运维Linux和python

序言

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

    在众多软件职业中，一直以为运维的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，都是傻逼制定的，这种傻逼一定要怼，怼到死。。。嗯。。。最终受伤害的只会是自己，但是不伤害一下，怎么成长，怎么见识一下人生的套路。。。

风言风语

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

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

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

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