本文來自微信公眾號(hào)“twt企業(yè)IT社區(qū)”，作者/曾祥滿，某股份制銀行存儲(chǔ)架構(gòu)師。
存儲(chǔ)作為存放金融企業(yè)數(shù)據(jù)中心各類生產(chǎn)數(shù)據(jù)的重要載體，其日常的安全平穩(wěn)運(yùn)行至關(guān)重要。特別是應(yīng)對(duì)若干存儲(chǔ)的大量告警，如何從大量告警中提取關(guān)鍵告警消息并及時(shí)處理異常，可謂對(duì)存儲(chǔ)平臺(tái)的穩(wěn)定運(yùn)行起到保駕護(hù)航的作用。
存儲(chǔ)告警處理作為常規(guī)工作，一方面需要在技術(shù)層面上及時(shí)發(fā)現(xiàn)告警并處理，另一方面還要在制度層面符合ITIL流程管理的規(guī)定。存儲(chǔ)告警中硬盤及電池的告警相對(duì)較多，此類告警出現(xiàn)時(shí)通常需要更換備件解決，且更換操作均屬于標(biāo)準(zhǔn)流程。因此，存儲(chǔ)硬件類告警的日常處理，如果兼顧流程、實(shí)際情況能納入自動(dòng)化管理，對(duì)于工作效率的提升將十分明顯。下面分別介紹“傳統(tǒng)、目前、未來”三個(gè)階段在發(fā)現(xiàn)存儲(chǔ)故障、提交廠商信息報(bào)修、同步ITIL流程三個(gè)方面的具體情況，旨在幫助讀者更好地了解在自動(dòng)化推進(jìn)中各階段亟需解決的問題。
一、傳統(tǒng)存儲(chǔ)故障處理流程
1.發(fā)現(xiàn)存儲(chǔ)故障
機(jī)房值班人員通過每天定期現(xiàn)場(chǎng)巡檢，借助存儲(chǔ)物理亮燈可以發(fā)現(xiàn)異常情況并告知存儲(chǔ)運(yùn)維人員進(jìn)行處理。由于人工巡檢頻率較低，發(fā)現(xiàn)異常相對(duì)比較滯后，且存在漏檢可能。為了能及時(shí)發(fā)現(xiàn)存儲(chǔ)設(shè)備存在的告警，早期通過在各存儲(chǔ)管理平臺(tái)配置SNMP Trap，將告警信息由運(yùn)行監(jiān)控中心發(fā)送給存儲(chǔ)運(yùn)維人員。這類告警即時(shí)性相當(dāng)高，有效輔助運(yùn)維人員在第一時(shí)間發(fā)現(xiàn)設(shè)備異常，但告警消息數(shù)目較多且缺乏過濾及壓縮，也給運(yùn)維人員的日常工作帶來了一定的困擾。
2.提交廠商日志確認(rèn)并安排維修
SNMP Trap類告警消息因缺少設(shè)備序列號(hào)、機(jī)柜位置、部件位置、部件規(guī)格等明確信息，無法直接轉(zhuǎn)發(fā)給廠商工程師進(jìn)行設(shè)備報(bào)修，一般需要單獨(dú)收集相關(guān)日志發(fā)送給廠商進(jìn)一步分析，或者需要運(yùn)維人員通過命令行或GUI等工具反饋具體信息給廠商。設(shè)備報(bào)修要求出具相關(guān)部件的準(zhǔn)確信息，而基于一定規(guī)則定制的告警消息無疑將使報(bào)修流程化繁為簡，在日常運(yùn)維中將節(jié)省大量的時(shí)間。
3.納入ITIL流程
存儲(chǔ)硬件更換在制度上納入ITIL流程變更管理，通常需要由存儲(chǔ)運(yùn)維人員在ITIL管理平臺(tái)申請(qǐng)事件工單和變更工單。運(yùn)維人員梳理設(shè)備告警情況，并跟廠商確認(rèn)好部件更換工作，先在ITIL管理平臺(tái)中提出事件工單，然后關(guān)聯(lián)此事件工單創(chuàng)建變更工單。事件工單經(jīng)服務(wù)臺(tái)確認(rèn)后需要運(yùn)維人員反饋事件原因和解決方案。變更工單經(jīng)變更經(jīng)理審核后需運(yùn)維人員制定方案，并依次經(jīng)變更經(jīng)理、室經(jīng)理、分管負(fù)責(zé)人審批后方能實(shí)施。變更實(shí)施完成后，運(yùn)維人員還需要在事件工單和變更工單中說明變更時(shí)間和實(shí)施情況，如圖1所示。
圖1傳統(tǒng)階段存儲(chǔ)故障處理流程示意圖
二、目前存儲(chǔ)故障處理流程
1.發(fā)現(xiàn)存儲(chǔ)故障
引入硬件監(jiān)控平臺(tái)，按照一定的時(shí)段輪詢獲取各品牌型號(hào)存儲(chǔ)的告警信息。此類告警較Trap而言即時(shí)性相對(duì)較差，但采用了一定的規(guī)則過濾出等級(jí)較高的信息進(jìn)行推送。告警消息少而精，便于定制，能更好地滿足運(yùn)維人員的日常管理要求。例如，針對(duì)重復(fù)的告警，可以采用壓縮算法，通常可以4小時(shí)報(bào)一次，直到問題解決。針對(duì)info、warning等較低級(jí)別的告警可以實(shí)現(xiàn)過濾，而只給運(yùn)維人員推送error和critical等較高級(jí)別的告警。
2.提交廠商關(guān)鍵信息并派件維修
借助硬件監(jiān)控平臺(tái)的廣泛使用，設(shè)備告警消息通過運(yùn)行監(jiān)控中心按一定規(guī)則拼接后可以發(fā)送給運(yùn)維人員。對(duì)于絕大多數(shù)情況，運(yùn)維人員無需再登陸系統(tǒng)進(jìn)行二次確認(rèn)，直接可將告警消息轉(zhuǎn)發(fā)給廠商人員即可安排派件維修。
3.納入ITIL流程
同傳統(tǒng)階段，運(yùn)維人員仍需在日常工作中消耗一定的時(shí)間和精力來申請(qǐng)事件及變更工單并跟進(jìn)流轉(zhuǎn)。如圖2所示。
圖2目前階段存儲(chǔ)故障處理流程示意圖
三、未來存儲(chǔ)故障處理流程
前兩個(gè)階段在變更實(shí)施和ITIL流程管理上，兩條線相對(duì)獨(dú)立尚未進(jìn)行融合，這與自動(dòng)化運(yùn)維管理仍有一定的差距。為進(jìn)一步優(yōu)化日常存儲(chǔ)告警的處理工作，未來應(yīng)著力于在ITIL流程中實(shí)現(xiàn)工單中模板化的東西由系統(tǒng)推送，并根據(jù)監(jiān)控平臺(tái)推送的恢復(fù)告警來自動(dòng)反饋工單的解決方案和實(shí)施情況等信息。
1.發(fā)現(xiàn)存儲(chǔ)故障和判斷故障恢復(fù)
目前硬件監(jiān)控平臺(tái)只能抓取設(shè)備的異常告警，對(duì)于故障修復(fù)后未能生成恢復(fù)類告警，需要人工參與判斷是否完成故障修復(fù)。若監(jiān)控平臺(tái)對(duì)于特定設(shè)備能及時(shí)判斷故障是否修復(fù)并生成恢復(fù)告警，則有益于推進(jìn)ITIL流程的自動(dòng)化管理，極大減少人工參與環(huán)節(jié)。
2.提交廠商關(guān)鍵信息并派件維修
此部分盡可能針對(duì)不同品牌型號(hào)的存儲(chǔ)及不同部件，進(jìn)一步細(xì)化告警信息，從而實(shí)現(xiàn)告警消息轉(zhuǎn)發(fā)后的正常派件維修即可。
3.ITIL流程自動(dòng)化審批
硬件監(jiān)控平臺(tái)將收集到的異常告警及時(shí)推送至智能平臺(tái)。智能平臺(tái)加工整合收集到的異常告警，識(shí)別出常見的壞件告警（例如硬盤、電池告警），并基于選定的時(shí)間范圍，按照既定的模板向ITIL管理平臺(tái)提交事件工單和變更工單申請(qǐng)。變更工單經(jīng)變更經(jīng)理審核確認(rèn)后，由智能平臺(tái)提供模板完成方案制定環(huán)節(jié)的提交。ITIL管理平臺(tái)在事件工單經(jīng)服務(wù)臺(tái)審批后發(fā)送給智能平臺(tái)處理，并將變更工單實(shí)施環(huán)節(jié)發(fā)送至智能平臺(tái)進(jìn)行處理。后續(xù)由硬件監(jiān)控平臺(tái)捕捉設(shè)備告警是否修復(fù)，如正常完成修復(fù)，向智能平臺(tái)及時(shí)推送恢復(fù)告警消息。智能平臺(tái)最終基于恢復(fù)告警消息，向ITIL管理平臺(tái)反饋實(shí)施情況從而關(guān)閉相關(guān)工單。顯然，智能平臺(tái)承擔(dān)了運(yùn)維人員ITIL流程管理相關(guān)的工作，其對(duì)監(jiān)控告警的識(shí)別和整合發(fā)揮著不可替代的作用。如圖3所示。
綜上所述，為了提升存儲(chǔ)告警處理的自動(dòng)化運(yùn)維管理水平，一方面需要在告警消息的精準(zhǔn)推送上下功夫，在硬件監(jiān)控平臺(tái)新增恢復(fù)告警，減少告警定位和設(shè)備報(bào)修中帶來的時(shí)間人力開銷；另一方面還需要打造智能平臺(tái)，促進(jìn)硬件監(jiān)控平臺(tái)和ITIL管理平臺(tái)自然銜接，從而替代運(yùn)維人員做好流程管理的跟進(jìn)及反饋等工作。
