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扭曲，将会一直存在下去。