透過谷歌宕機事故看存儲運維三大重要趨勢

近日，谷歌又出現(xiàn)大面積癱瘓事件，導(dǎo)致全球范圍內(nèi)多款Google服務(wù)崩潰，這已經(jīng)是谷歌近半年第三次出現(xiàn)大規(guī)模宕機事件，堪稱上演宕機“帽子戲法”。

回顧此次宕機事件，谷歌在出現(xiàn)宕機之后的反應(yīng)倒是挺快。根據(jù)谷歌云官方推特表述，經(jīng)過谷歌運維工程師近50分鐘的緊急處理，相關(guān)服務(wù)在當(dāng)?shù)貢r間凌晨4點32分恢復(fù)正常，真是“同是天涯運維人，凌晨加班曾相識”。

再來看看此次宕機事件的“元兇”--“internal storage quota issue”，谷歌后續(xù)的一份初步調(diào)查報告中稱：此次宕機的原因是“我們的自動配額管理系統(tǒng)出現(xiàn)了問題，降低了谷歌中央身份管理系統(tǒng)的容量，導(dǎo)致其在全球范圍內(nèi)返回錯誤。因此，我們無法驗證用戶請求是否經(jīng)過認(rèn)證，并向用戶提供錯誤。”

何謂“自動配額管理”問題？難道之前大部分媒體報道的“磁盤寫滿”宕機原因都是錯的？亦或是“磁盤寫滿”是表象，“自動配額管理”才是誘因？帶著好奇心，大數(shù)據(jù)在線小編找到了資深存儲專家李工，請他詳細(xì)分析了此次谷歌宕機事件背后的大瓜。

請教完大神之后，小編對數(shù)據(jù)中心當(dāng)前運維情況進行了一番調(diào)研?，F(xiàn)階段，金融、政務(wù)、交通等行業(yè)的數(shù)據(jù)中心，無論是規(guī)模、設(shè)備數(shù)量還是應(yīng)用種類、復(fù)雜性都遠(yuǎn)勝過去。Gartner首席分析師Pankaj Prasad分析，企業(yè)IT基礎(chǔ)架構(gòu)和應(yīng)用程序所產(chǎn)生的數(shù)據(jù)量正以每年2-3倍的速度增長，其中像指標(biāo)、日志等機器所產(chǎn)生的數(shù)據(jù)類型多樣且增長迅速，未來會給運維帶來極大挑戰(zhàn)。

根據(jù)相關(guān)調(diào)查數(shù)據(jù)顯示，隨著全球數(shù)據(jù)規(guī)模的爆炸性增長，在企業(yè)數(shù)據(jù)中心的故障中，存儲設(shè)備相關(guān)故障已經(jīng)占到70%以上，成為數(shù)據(jù)中心故障的“主力軍”，以某國際互聯(lián)網(wǎng)社交企業(yè)為例，每天需要修復(fù)數(shù)據(jù)24TB，每天因修復(fù)帶來的跨機架流量高達180TB。并且，近期銀行、證券等金融行業(yè)也是頻頻故障癱瘓，有著深厚先進技術(shù)積累的科技、金融領(lǐng)域企業(yè)尚且在運維上頻頻觸礁，其他領(lǐng)域的風(fēng)險和困境可想而知。

可以說，解決存儲設(shè)備故障問題等于給數(shù)據(jù)中心買來一份“保險”。顯然，在數(shù)據(jù)中心技術(shù)和新應(yīng)用的層出不窮的今天，傳統(tǒng)運維依然高度依賴人的經(jīng)驗和人的精力，運維人員就像一群救火隊員，不是在解決問題就是在解決問題的路上，以至于好多運維人員感嘆自己是操著賣白粉的心賺著賣白菜的錢。。。

如何拯救運維人員于水火之中？徹底解決數(shù)據(jù)中心復(fù)雜化帶來的運維復(fù)雜化？智能運維絕對是大勢所趨，小編也大致分析了一下當(dāng)前智能運維解決方案的近況。當(dāng)前，智能運維圍繞設(shè)備異常、容量預(yù)警等關(guān)鍵場景，融入AI相關(guān)特性，讓運維走向自動化和智能化，但號稱智能運維解決方案的多如牛毛，你搜索一下，搞不好是“X田系”搞的……小編又請教了一下存儲大牛老李，他說需要從三個方面來衡量一款智能運維解決方案的優(yōu)劣。

首先需要具備容量預(yù)測能力（設(shè)備側(cè)+云端均具備）。假設(shè)客戶能夠提前預(yù)知陣列或存儲池，甚至是更細(xì)粒度對象的容量變化趨勢，那么容量配額不足導(dǎo)致服務(wù)宕機的發(fā)生可能性則會大大降低。智能運維解決方案需要云上+本地聯(lián)動運維能力，并且能夠基于時序預(yù)測等關(guān)鍵技術(shù)，最好可以向客戶提供未來最長365天的容量趨勢預(yù)測，并能夠提前預(yù)警80%配額，提醒用戶提前擴容。

其次需要具備風(fēng)險盤預(yù)測能力（異常檢測模型服務(wù)提前14天預(yù)測硬盤故障），智能運維方案需要每日采集數(shù)據(jù)中心硬盤數(shù)據(jù)（硬盤ID、SN、硬盤非安全斷電次數(shù)、通電時長）,從歷史數(shù)據(jù)中識別硬盤不同屬性的突變模式對當(dāng)前狀態(tài)進行預(yù)測，結(jié)合用戶反饋數(shù)據(jù)，定期執(zhí)行模型自優(yōu)化，持續(xù)提升預(yù)測精度，并且為數(shù)據(jù)中心硬盤提供主動運維。風(fēng)險盤預(yù)測能力考驗的是方案商的算法模型能力，突變模型服務(wù)企業(yè)越多、模型訓(xùn)練越久，識別風(fēng)險故障就越正確。

如果廠商一上來就說自己模型準(zhǔn)確率高達99.9%，這十有八九是騙子，勸你趕緊報警。

最后，具備存儲性能異常預(yù)測管理能力（圍繞存儲性能相關(guān)問題提供全面分析處理方案）。這種能力又分為三塊：第一是性能預(yù)測及潮汐預(yù)警，需要基于時間序列預(yù)測等關(guān)鍵技術(shù)的性能預(yù)測特性以及基于閾值觸發(fā)的性能潮汐預(yù)警，能夠讓客戶預(yù)知設(shè)備關(guān)鍵性能指標(biāo)變化趨勢（如時延、IOPS、塊帶寬），提早發(fā)現(xiàn)設(shè)備性能瓶頸點，輔助客戶盡早規(guī)避可能發(fā)生的異常；

另外，第二是性能異常檢測與根因定界分析，針對“傳統(tǒng)的專家經(jīng)驗規(guī)則或靜態(tài)閾值預(yù)警，無法覆蓋大多數(shù)性能異常場景，且可能存在誤報漏報的情況”，方案可以基于機器學(xué)習(xí)的關(guān)鍵性能KPI異常檢測及根因定界特性，無監(jiān)督自學(xué)習(xí)的異常檢測模型能夠?qū)崟r檢測設(shè)備時延是否異常，異常檢測準(zhǔn)確率越高越好；另外有些廠商在存儲設(shè)備中內(nèi)置基于多集成樹算法融合模型，外加皮爾遜相關(guān)性關(guān)聯(lián)分析算法，實現(xiàn)異常根因的定界分析，大幅提升客戶發(fā)現(xiàn)性能問題、定位問題邊界的效率。

第三就是常見性能故障自修復(fù)，有能力將逐步實現(xiàn)異常場景的快速自愈，降低客戶運維門檻，降低客戶運維成本，實時保障客戶業(yè)務(wù)不受干擾。

小編又進一步調(diào)研了當(dāng)前的市場情況，在眾多數(shù)據(jù)中心智能運維解決方案中，以華為為代表中國廠商的解決方案近年來不斷進步，甚至達到了業(yè)界領(lǐng)先水平。以華為數(shù)據(jù)管理引擎DME為例，目前在銀行、證券、政府等多個行業(yè)廣泛應(yīng)用，在保護用戶數(shù)據(jù)隱私的前提下，有效地幫助金融等行業(yè)用戶構(gòu)建構(gòu)筑端到端的感知能力、智能的分析能力以及可信的執(zhí)行能力來實現(xiàn)運維自動化閉環(huán)，大幅提升運維和資源利用效率。

面向未來，隨著智能運維技術(shù)的不斷成熟與完善，小編相信數(shù)據(jù)中心運維人員不再是那個忙得四腳朝天的“熱鍋螞蟻”，而是故障圍困萬千重，我自巋然不動，任憑風(fēng)云起，穩(wěn)坐釣魚臺，談笑間，故障已灰飛煙滅。

生成海報

免責(zé)聲明：此文內(nèi)容為第三方自媒體作者發(fā)布的觀察或評論性文章，所有文字和圖片版權(quán)歸作者所有，且僅代表作者個人觀點，與極客網(wǎng)無關(guān)。文章僅供讀者參考，并請自行核實相關(guān)內(nèi)容。投訴郵箱：editor@fromgeek.com。

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。