被KPI歪曲的运维

4月29号的文章发了之后，很多好友给我留言探讨。有些人觉得我所说的以业务升级来防止更大的缺点的方法只是预先诸葛亮，由于只要现在知道结果才干如此武断地执行，在实践运维上班中恐怕很难做到，由于无论缺点多大，中止服务都是十分重大的意外，会让运维部门接受难以接受的结果。

实践上这些顾忌都是实在的，从这些顾忌中也可以看出被KPI歪曲的运维治理有如容许怕。

十多年前，我去一个客户那边做巡检。采集数据的时刻发现运维组突然乱了起来，说是一套外围系统的RAC的 一个节点突然宕机了。

我帮助看了一下，正好是业务高峰期，系统负载不低，单节点宕机后，运行都切到另外一个 节点上了，那个节点的负载也很高，GC REMASTER速度有点慢，不过还对付能接受，而关于宕机的实例，宕机前发生了一些ORA-600和ORA-7445，报错消息比拟生疏，须要进一步剖析。

我倡导他们先查查宕机要素，不急着重启，等几个小时后业务高峰过去后，并且曾经搞明白了实例宕机的要素再重启缺点节点。反合理前业务延续性也没遭到重大影响。

DBA主管坚持要立刻重启数据库，他说假设不能在30分钟内复原实例，他们会被扣绩效。过后我就十分不了解这种绩效考核，RAC还有一个节点反常上班，业务延续性是没疑问的，为啥还要影响DBA的绩效。

经过一顿匆忙的操作，缺点实例没有复原，反而好的那个节点也智能重启了。于是只能封锁两个节点，而后从新启动。整个处置环节形成了业务停服30分钟+，依照公司的考核规则是一个四级意外。

另外一个例子愈加搞笑，也是十多年前的事件了，月底给一家银行做巡检的时刻发现RAC的一个节点由于遇到Oracle 10g的一个BUG，RAC两个节点的共享池都发生了较为重大的碎片。

这个疑问只能经过重启数据实例来处置疑问，我倡导他们尽快在早晨买卖量较少的时刻放开一次性重启，一个实例一个实例来，先重启共享池碎片比拟重大的那个实例。过后银行的DBA主管和我一同探讨了重启的打算，说争取早晨就把这个变卦做了。

第二天我和他在微信上聊了几句，问他数据库重启了没有。他说放开没取得同意，由于依据考核要求，本月的停机检修期间曾经满了，反正月底了，下周再搞吧。过后我想离下周也只要几天时间了，也没当回事。没想到第二天下午3点多，系统就出小事了。那个碎片更为重大的节点首先少量报ORA-4031,而后就宕机了。

在RAC RECONFIG的时刻，活着的节点又HANG住了，业务卡顿了五六分钟才逐渐复原反常。半个小时内发生了少量外围买卖超时和失败，DBA团队被扣绩效是没跑了。

从90年代DBA把握运维的相对话语权，业务高峰时都可以随时要求系统重启数据库到如今企业十分规范的IT治理，在治理上的提高是十分渺小的。然而在严厉的KPI治理下，运维上班的精气实质也被歪曲了。

很多时刻，运维不是为了让系统跑得更好，而是为了满足KPI的要求，因此很多运维上班都是围绕KPI的，而不是围绕运维的最终目的的。

不过在目前的运维技术才干撑持下，除了KPI是十分直观的，其余的一切似乎都有些玄幻。第一个例子中，假设不尽快复原缺点节点，假设反常节点再宕了，运维部门是接受不了的。而咱们无法确保活着的节点不出疑问，因此就无法不制订这样的治理要求。

假设咱们能够确保或许的节点在营业厅关门前不会宕机，那么咱们还须要立刻去复原缺点节点吗？亦或是这套RAC集群假设有三个节点，咱们还须要立刻去做恢停上班吗？KPI不能保证系统的可用性，合理的架构才可以。

在第二个案例中，SLA的KPI只管关键，然而KPI也不能凌驾于运转安保之上。假设遇到有较为紧急的运维变卦操作，是不是可以通融一次性呢？实践上这个事件关于指导来说也是个难题，由于DBA无法量化缺点危险，因此指导也无法在KPI和运维危险之间做出正确的判别。

假设DBA明白通知指导，系统不重启，第二天十有八九会出意外，我想在指导眼里，KPI都可以见鬼去了。惋惜过后DBA和我都没有给出一个十分量化的论断，以致于这件事的优先级没有被足够优化，DBA也错失了一次性罪恶的时机。从另一个角度看，假设过后做了重启，系统复原反常了，谁又会知道DBA立了功呢？

为什么会发生KPI歪曲运维的疑问呢？基于KPI的治理体系自身没有疑问，有疑问的其实是咱们的运维体系。

由于咱们的运维上班还没有数字化，没有从系统运转中抽取出片面合理的系统运转形态关系的目的并添加到KPI体系中，因此一切的KPI都是面向治理的，没有面向系统运转形态自身的 ，在大少数企业里，KPI都会存在重大背叛运维上班实质的方面。假设不能很好地处置这些疑问，那么咱们的运维上班中的这种KPI歪曲，将会不时存在下去。