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