4月29號的文章發(fā)了之后，很多朋友給我留言討論。有些人覺得我所說的以業(yè)務降級來避免更大的故障的方法只是事后諸葛亮，因為只有當初知道后果才能如此果決地行動，在實際運維工作中恐怕很難做到，因為無論故障多大，停止服務都是十分嚴重的事故，會讓運維部門承受難以承受的后果。

實際上這些顧慮都是真實的，從這些顧慮中也可以看出被KPI扭曲的運維管理有多么可怕。

十多年前，我去一個客戶那邊做巡檢。采集數據的時候發(fā)現運維組突然亂了起來，說是一套核心系統的RAC的 一個節(jié)點突然宕機了。

我?guī)兔戳艘幌拢檬菢I(yè)務高峰期，系統負載不低，單節(jié)點宕機后，應用都切到另外一個 節(jié)點上了，那個節(jié)點的負載也很高，GC REMASTER速度有點慢，不過還湊合能接受，而對于宕機的實例，宕機前出現了一些ORA-600和ORA-7445，報錯信息比較陌生，需要進一步分析。

我建議他們先查查宕機原因，不急著重啟，等幾個小時后業(yè)務高峰過去后，并且已經搞明白了實例宕機的原因再重啟故障節(jié)點。反正當前業(yè)務連續(xù)性也沒受到嚴重影響。

DBA主管堅持要立即重啟數據庫，他說如果不能在30分鐘內恢復實例，他們會被扣績效。當時我就十分不理解這種績效考核，RAC還有一個節(jié)點正常工作，業(yè)務連續(xù)性是沒問題的，為啥還要影響DBA的績效。

經過一頓匆忙的操作，故障實例沒有恢復，反而好的那個節(jié)點也自動重啟了。于是只能關閉兩個節(jié)點，然后重新啟動。整個處置過程造成了業(yè)務停服30分鐘+，按照公司的考核規(guī)定是一個四級事故。

另外一個例子更加搞笑，也是十多年前的事情了，月底給一家銀行做巡檢的時候發(fā)現RAC的一個節(jié)點因為遇到Oracle 10g的一個BUG，RAC兩個節(jié)點的共享池都出現了較為嚴重的碎片。

這個問題只能通過重啟數據實例來解決問題，我建議他們盡快在晚上交易量較少的時候申請一次重啟，一個實例一個實例來，先重啟共享池碎片比較嚴重的那個實例。當時銀行的DBA主管和我一起討論了重啟的方案，說爭取晚上就把這個變更做了。

第二天我和他在微信上聊了幾句，問他數據庫重啟了沒有。他說申請沒獲得批準，因為根據考核要求，本月的停機檢修時間已經滿了，反正月底了，下周再搞吧。當時我想離下周也只有幾天時間了，也沒當回事。沒想到第二天下午3點多，系統就出大事了。那個碎片更為嚴重的節(jié)點首先大量報ORA-4031,然后就宕機了。

在RAC RECONFIG的時候，活著的節(jié)點又HANG住了，業(yè)務卡頓了五六分鐘才逐漸恢復正常。半個小時內出現了大量核心交易超時和失敗，DBA團隊被扣績效是沒跑了。

從90年代DBA掌握運維的絕對話語權，業(yè)務高峰時都可以隨時要求系統重啟數據庫到現在企業(yè)十分規(guī)范的IT管理，在管理上的進步是十分巨大的。但是在嚴格的KPI管理下，運維工作的精神本質也被扭曲了。

很多時候，運維不是為了讓系統跑得更好，而是為了滿足KPI的要求，因此很多運維工作都是圍繞KPI的，而不是圍繞運維的最終目標的。

不過在目前的運維技術能力支撐下，除了KPI是十分直觀的，其他的一切似乎都有些玄幻。第一個例子中，如果不盡快恢復故障節(jié)點，如果正常節(jié)點再宕了，運維部門是承受不了的。而我們無法確保活著的節(jié)點不出問題，因此就無法不制定這樣的管理要求。

如果我們能夠確保或者的節(jié)點在營業(yè)廳關門前不會宕機，那么我們還需要立即去恢復故障節(jié)點嗎？亦或是這套RAC集群如果有三個節(jié)點，我們還需要立即去做恢復工作嗎？KPI不能保障系統的可用性，合理的架構才可以。

在第二個案例中，SLA的KPI雖然重要，但是KPI也不能凌駕于運行安全之上。如果遇到有較為緊急的運維變更操作，是不是可以通融一次呢？實際上這個事情對于領導來說也是個難題，因為DBA無法量化故障風險，因此領導也無法在KPI和運維風險之間做出正確的判斷。

如果DBA明確告訴領導，系統不重啟，第二天十有八九會出事故，我想在領導眼里，KPI都可以見鬼去了。可惜當時DBA和我都沒有給出一個十分量化的結論，以至于這件事的優(yōu)先級沒有被足夠提升，DBA也錯失了一次立功的機會。從另一個角度看，如果當時做了重啟，系統恢復正常了，誰又會知道DBA立了功呢？

為什么會出現KPI扭曲運維的問題呢？基于KPI的管理體系本身沒有問題，有問題的其實是我們的運維體系。

因為我們的運維工作還沒有數字化，沒有從系統運行中抽取出全面合理的系統運行狀態(tài)相關的指標并加入到KPI體系中，因此所有的KPI都是面向管理的，沒有面向系統運行狀態(tài)本身的 ，在大多數企業(yè)里，KPI都會存在嚴重背離運維工作本質的方面。如果不能很好地處理這些問題，那么我們的運維工作中的這種KPI扭曲，將會一直存在下去。