IT事故能真正實現(xiàn)防患于未然嗎？

申請免費試用、咨詢電話：400-8352-114

 防患于未然：避免設(shè)備管理系統(tǒng)事故遠比補救措施更加重要

2012-09-25 09:51 核子可樂譯 51CTO.com 我要評論(1) 字號：T | T   應(yīng)用程序性能管理起來既變化多樣、又復(fù)雜難馴。時至今日，設(shè)備管理系統(tǒng)部門為了滿足業(yè)務(wù)形勢的各種需求，不得不在意外情況實際發(fā)生前就對問題進行預(yù)判，并詳細規(guī)劃修復(fù)故障可能耗費的時間——也就是MTTR（即平均修復(fù)時間）。換句話來說，僅僅及時做出反應(yīng)已經(jīng)無法取悅消費者，現(xiàn)在技術(shù)人員必須在用戶尚未感受到之前，就將問題扼殺在萌芽狀態(tài)。   歷史在前進、形勢在變化   云遷移、移動技術(shù)、BYOD等多種新興技術(shù)趨勢都帶來了極度復(fù)雜的管理機制，這就迫使設(shè)備管理系統(tǒng)部門不能再滿足于傳統(tǒng)的識別及修復(fù)工作，而需要走在問題的前面?，F(xiàn)在，技術(shù)團隊必須能夠預(yù)測可能出現(xiàn)的情況、了解評估故障可能需要的時間，并最終實現(xiàn)關(guān)鍵性業(yè)務(wù)應(yīng)用程序始終擁有最佳性能表現(xiàn)。事實上，各種跡象表明我們甚至已經(jīng)初步擁有了能夠在故障實際發(fā)生之前就將其解決的先進技術(shù)能力。   如今以MTT開頭的縮寫詞家族可謂人丁興旺，從平均診斷時間（簡稱MTTI）、平均修復(fù)時間（簡稱MTTR）再到最新的平均預(yù)測時間（簡稱MTTP）——每個新生詞匯都代表著市場向技術(shù)團隊提出的新要求，這種迅猛的變化趨勢確實令人頭痛?？梢哉f以上三套基準都意義重大、極具價值，標志著技術(shù)運營的階段性發(fā)展方向，而企業(yè)用戶最關(guān)心的自然是這些突破性技術(shù)如何才能真正融入日常工作。在競爭壓力下，設(shè)備管理系統(tǒng)部門不得不將負責范疇進一步擴大，嘗試在故障發(fā)生之前就將其解決——這將進一步降低技術(shù)工具對終端用戶的技能需求，使整套業(yè)務(wù)方案更為易用。   可預(yù)測性已經(jīng)成為應(yīng)用程序性能管理工作中的關(guān)鍵環(huán)節(jié)，而且技術(shù)分析人士已經(jīng)不再滿足于僅僅對處理時間做出預(yù)估。目前我們還只是對應(yīng)用程序使用情況進行分析，但新時代的技術(shù)團隊能夠緊密追蹤宏觀行為模式。此外，整個分析流程都必須以自動化方式進行，因為面對如此規(guī)模的計算量，人力根本無法帶來任何幫助。當然，這只是一種展望，目前我們還不能完成如此復(fù)雜的自動化處理工作。   就在不久前，汽車愛好者們還喜歡在引擎蓋下面大做文章，希望能榨干自己改裝車發(fā)動機的最后一點潛能。如今，隨著機動車整體運轉(zhuǎn)機制的復(fù)雜性與自動化芯片的廣泛使用，隨便拿套工具就能為愛車加力的日子一去不復(fù)返了。與之類似，今天的企業(yè)級應(yīng)用程序堆棧也面臨著同樣的問題——太過復(fù)雜精密、難以按需修改。   自動化實時預(yù)測分析技術(shù)如今迎來了發(fā)展過程中的全新篇章，其中以云基礎(chǔ)及混合環(huán)境為代表，這幾乎徹底改變了應(yīng)用性能管理領(lǐng)域的游戲規(guī)則。因此，我們不妨以改裝愛車的熱情來看待應(yīng)用性能管理所面臨的技術(shù)風潮——這種突破性理念不僅能夠幫助設(shè)備管理系統(tǒng)部門專注于創(chuàng)新及業(yè)務(wù)支持、緩和設(shè)施故障，更使技術(shù)人員得以利用預(yù)測來代替修復(fù)、擺脫操作干擾，同時用戶也能獲得值得依賴的應(yīng)用程序性能預(yù)估結(jié)論。   很長一段時間以來，“向云環(huán)境遷移”、“設(shè)備管理系統(tǒng)消費化趨勢”、“混合型設(shè)備管理系統(tǒng)環(huán)境”以及BYOD等話題都被視為技術(shù)話題的重心，其中無疑存在大量炒作傾向。不過我們?nèi)匀灰姓J，這里提到的每一個話題都擁有改變游戲規(guī)則的力量，同時也為現(xiàn)有業(yè)務(wù)系統(tǒng)帶來諸多創(chuàng)新空間與技術(shù)挑戰(zhàn)。說到挑戰(zhàn)，上述新技術(shù)給終端用戶帶來的技能要求可能是眾多問題中最難辨別也最難迅速解決的環(huán)節(jié)。   有鑒于此，預(yù)測概念的誕生就顯得更加重要。很多專家仍然鼓吹利用傳統(tǒng)的時間序列數(shù)據(jù)分析機制來進行問題診斷、安全提示或警報閾值——但他們顯然忽視了新形勢所帶來的新情況：隨著網(wǎng)絡(luò)化進程的普及與發(fā)展，分布式特性已經(jīng)使應(yīng)用程序的復(fù)雜性與關(guān)聯(lián)性大幅提升。   目前我們已經(jīng)發(fā)現(xiàn)了一種相當有趣的方案，能夠?qū)M跨多種互聯(lián)端點的網(wǎng)絡(luò)負載行為及分布式應(yīng)用程序產(chǎn)生深遠影響——它不僅能夠準確把握設(shè)備的處理速度，同時還能根據(jù)終端用戶的不同服務(wù)水平協(xié)議將資源進行合理分配。這套方案不同于以往的行為學(xué)習（簡稱BL）機制，它突破性地利用多種考核維度來分析應(yīng)用程序的使用情況。這種名為使用模式的多用戶多事務(wù)行為管理方案將每一分鐘加以充分利用，意外情況再也不可能在技術(shù)人員的監(jiān)管之外肆意妄為了。   應(yīng)用程序行為學(xué)習（簡稱ABL）會捕捉并分析實時數(shù)據(jù)，及時反饋應(yīng)用程序基礎(chǔ)設(shè)施中各層的實際性能狀態(tài)，并整理出終端用戶所感受到的真實使用體驗。ABL會針對應(yīng)用程序性能創(chuàng)建出動態(tài)，同時利用統(tǒng)計相關(guān)性與模式匹配技術(shù)自動發(fā)現(xiàn)各基礎(chǔ)設(shè)施組件的性能閾值。閾值自動發(fā)現(xiàn)（簡稱ATD）方案能夠大大降低管理工作對人力的依賴并減輕配置工作負擔。   分析機制還提供早期預(yù)警功能，能夠深入探詢基礎(chǔ)設(shè)施關(guān)鍵性效能指標（簡稱KPI），并將異常情況及時反饋給管理人員。在預(yù)警功能的強大輔助之下，技術(shù)人員能夠更快地進行根本原因分析（簡稱RCA）工作以及自動修復(fù)流程。   ABL在對關(guān)鍵性應(yīng)用程序性能指標的歷史及實時數(shù)據(jù)集進行匯總時，采用了相當復(fù)雜的分析算法。到目前為止，系統(tǒng)、數(shù)據(jù)庫及存儲管理者一直都在以手動方式利用這類方案進行監(jiān)控及故障排查，這種“亡羊補牢”的笨辦法正是眼下的主流機制。ABL將問題檢測、故障排查重點以及生產(chǎn)環(huán)境下的爭議性問題等技術(shù)挑戰(zhàn)以自動化形式完成，這就回避了傳統(tǒng)分析方案的復(fù)雜性及人工效率低下等問題，同時保障了高性能事務(wù)處理應(yīng)用始終擁有充裕的可用資源。   在引入ABL及預(yù)測分析機制之后，設(shè)備管理系統(tǒng)部門能夠?qū)Ｗ⒂趯γ靠顟?yīng)用程序進行性能優(yōu)化，而不僅僅是優(yōu)化底層設(shè)備。相較于過去需要在幾分鐘或者幾小時內(nèi)完成問題檢測、事故修復(fù)并應(yīng)對一系列多層環(huán)境的基礎(chǔ)設(shè)施中心型應(yīng)用性能管理方案，預(yù)測分析機制能夠?qū)⒐ぷ鲝姸瓤刂圃谶^去的數(shù)分之一。設(shè)備管理系統(tǒng)如今可以在問題發(fā)生之前就做出預(yù)測并加以防范——在某些停機情況下，事前準備能夠以五到十小時的時間節(jié)約量快速解決故障。本文來自互聯(lián)網(wǎng)，僅供參考