4月29號(hào)的文章發(fā)了之后，很多朋友給我留言討論。有些人覺(jué)得我所說(shuō)的以業(yè)務(wù)降級(jí)來(lái)避免更大的故障的方法只是事后諸葛亮，因?yàn)橹挥挟?dāng)初知道后果才能如此果決地行動(dòng)，在實(shí)際運(yùn)維工作中恐怕很難做到，因?yàn)闊o(wú)論故障多大，停止服務(wù)都是十分嚴(yán)重的事故，會(huì)讓運(yùn)維部門(mén)承受難以承受的后果。

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

十多年前，我去一個(gè)客戶那邊做巡檢。采集數(shù)據(jù)的時(shí)候發(fā)現(xiàn)運(yùn)維組突然亂了起來(lái)，說(shuō)是一套核心系統(tǒng)的RAC的 一個(gè)節(jié)點(diǎn)突然宕機(jī)了。

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

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

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

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

另外一個(gè)例子更加搞笑，也是十多年前的事情了，月底給一家銀行做巡檢的時(shí)候發(fā)現(xiàn)RAC的一個(gè)節(jié)點(diǎn)因?yàn)橛龅絆racle 10g的一個(gè)BUG，RAC兩個(gè)節(jié)點(diǎn)的共享池都出現(xiàn)了較為嚴(yán)重的碎片。

這個(gè)問(wèn)題只能通過(guò)重啟數(shù)據(jù)實(shí)例來(lái)解決問(wèn)題，我建議他們盡快在晚上交易量較少的時(shí)候申請(qǐng)一次重啟，一個(gè)實(shí)例一個(gè)實(shí)例來(lái)，先重啟共享池碎片比較嚴(yán)重的那個(gè)實(shí)例。當(dāng)時(shí)銀行的DBA主管和我一起討論了重啟的方案，說(shuō)爭(zhēng)取晚上就把這個(gè)變更做了。

第二天我和他在微信上聊了幾句，問(wèn)他數(shù)據(jù)庫(kù)重啟了沒(méi)有。他說(shuō)申請(qǐng)沒(méi)獲得批準(zhǔn)，因?yàn)楦鶕?jù)考核要求，本月的停機(jī)檢修時(shí)間已經(jīng)滿了，反正月底了，下周再搞吧。當(dāng)時(shí)我想離下周也只有幾天時(shí)間了，也沒(méi)當(dāng)回事。沒(méi)想到第二天下午3點(diǎn)多，系統(tǒng)就出大事了。那個(gè)碎片更為嚴(yán)重的節(jié)點(diǎn)首先大量報(bào)ORA-4031,然后就宕機(jī)了。

在RAC RECONFIG的時(shí)候，活著的節(jié)點(diǎn)又HANG住了，業(yè)務(wù)卡頓了五六分鐘才逐漸恢復(fù)正常。半個(gè)小時(shí)內(nèi)出現(xiàn)了大量核心交易超時(shí)和失敗，DBA團(tuán)隊(duì)被扣績(jī)效是沒(méi)跑了。

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

很多時(shí)候，運(yùn)維不是為了讓系統(tǒng)跑得更好，而是為了滿足KPI的要求，因此很多運(yùn)維工作都是圍繞KPI的，而不是圍繞運(yùn)維的最終目標(biāo)的。

不過(guò)在目前的運(yùn)維技術(shù)能力支撐下，除了KPI是十分直觀的，其他的一切似乎都有些玄幻。第一個(gè)例子中，如果不盡快恢復(fù)故障節(jié)點(diǎn)，如果正常節(jié)點(diǎn)再宕了，運(yùn)維部門(mén)是承受不了的。而我們無(wú)法確?；钪墓?jié)點(diǎn)不出問(wèn)題，因此就無(wú)法不制定這樣的管理要求。

如果我們能夠確?；蛘叩墓?jié)點(diǎn)在營(yíng)業(yè)廳關(guān)門(mén)前不會(huì)宕機(jī)，那么我們還需要立即去恢復(fù)故障節(jié)點(diǎn)嗎？亦或是這套R(shí)AC集群如果有三個(gè)節(jié)點(diǎn)，我們還需要立即去做恢復(fù)工作嗎？KPI不能保障系統(tǒng)的可用性，合理的架構(gòu)才可以。

在第二個(gè)案例中，SLA的KPI雖然重要，但是KPI也不能凌駕于運(yùn)行安全之上。如果遇到有較為緊急的運(yùn)維變更操作，是不是可以通融一次呢？實(shí)際上這個(gè)事情對(duì)于領(lǐng)導(dǎo)來(lái)說(shuō)也是個(gè)難題，因?yàn)镈BA無(wú)法量化故障風(fēng)險(xiǎn)，因此領(lǐng)導(dǎo)也無(wú)法在KPI和運(yùn)維風(fēng)險(xiǎn)之間做出正確的判斷。

如果DBA明確告訴領(lǐng)導(dǎo)，系統(tǒng)不重啟，第二天十有八九會(huì)出事故，我想在領(lǐng)導(dǎo)眼里，KPI都可以見(jiàn)鬼去了。可惜當(dāng)時(shí)DBA和我都沒(méi)有給出一個(gè)十分量化的結(jié)論，以至于這件事的優(yōu)先級(jí)沒(méi)有被足夠提升，DBA也錯(cuò)失了一次立功的機(jī)會(huì)。從另一個(gè)角度看，如果當(dāng)時(shí)做了重啟，系統(tǒng)恢復(fù)正常了，誰(shuí)又會(huì)知道DBA立了功呢？

為什么會(huì)出現(xiàn)KPI扭曲運(yùn)維的問(wèn)題呢？基于KPI的管理體系本身沒(méi)有問(wèn)題，有問(wèn)題的其實(shí)是我們的運(yùn)維體系。

因?yàn)槲覀兊倪\(yùn)維工作還沒(méi)有數(shù)字化，沒(méi)有從系統(tǒng)運(yùn)行中抽取出全面合理的系統(tǒng)運(yùn)行狀態(tài)相關(guān)的指標(biāo)并加入到KPI體系中，因此所有的KPI都是面向管理的，沒(méi)有面向系統(tǒng)運(yùn)行狀態(tài)本身的 ，在大多數(shù)企業(yè)里，KPI都會(huì)存在嚴(yán)重背離運(yùn)維工作本質(zhì)的方面。如果不能很好地處理這些問(wèn)題，那么我們的運(yùn)維工作中的這種KPI扭曲，將會(huì)一直存在下去。