本文整理自 GOPS2017·上海站演講《從說到做-大型企業智能運維的360度解析》

講師簡介

孫傑，國內一線運維專家，從業十幾載的IT老兵，專註於系統、運維、雲計算和數據中心管理，先後在外企、互聯網、電商、大型企業任職，參與實施數據中心建設、私有雲架構規劃及運維管理、大數據挖掘等相關工作，在若干大中型項目的建設和部署運維中，積累了豐富的架構設計、項目實施和一線經驗。憑藉豐富的技術經驗和樂於分享精神，先後受邀出席全球雲計算峰會、可信雲大會、GOPS全球運維大會等全國性技術會議並發表熱點主題分享，受到廣泛好評。不僅是技術分享的推崇者，也是IT行業的實踐者、佈道者。

聽了有關AI運維之後有很多人感到比較焦慮，我所從事的運維或開發將來會不會被AI給替代掉呢？

現在新技術發展的特別快，各種語言、技術、理念讓大家確實感到自顧不暇跟不上趟，但是有一點，在這裡我要特別重申一下，AI在目前這個階段還是一種輔助大家來進行判斷和學習、定位處理問題的工具，就像無人駕駛，現在可以做到完全沒有人駕駛嗎？肯定不行，未來無人駕駛是完全可以替代人的，但它還有很長一段路要走。AI運維就像無人駕駛一樣，未來前景很光明，但任重道遠。

大部分的智能運維還沒有完全落地，我所在的企業也是處在一個探索的階段。在一個傳統的企業它的運維該如何走？從以前的腳本到工具、自動化，再到現在的智能運維，中間這個步驟該怎麼走？今天就從下面五個方面給大家分享下：

一、構建一個全面科學的IT運維管理體系

第一個IT部門的整體認可不足。雖然說IT在任何單位現在都是一個比較重要的部門，但是還有很多領導仍然認為它是一個成本中心，不是一個利潤中心，認為這個部門是花錢的，而不是像業務部門創造業務價值和創造利潤的。

第二個對於運維工作人員負荷比較大，工作模式不被員工認可。在沒有自動化運維和平台之前，整個運維團隊只有八個人，如果每個人一天處理六到十個故障，基本上沒有時間去研究別的東西了。傳統運維壓力很大，疲於奔命和救火，必須要尋求改變，走向自動化、平台化、智能化。

第三運行的態勢相關信息掌握不足。監控是多維度的，不同的業務會有不同的指標，所有加起來有上萬個指標，但卻沒有整體態勢變化圖、很難成體系，不能實現智能感知和態勢預測，整個運維態勢就很難保持平穩。

第四依據業務需求調整服務和設置資源的能力不足。在業務故障處理的時候需要很長的過程，中間涉及到很多的相關技術部門，需要和業務方進行交互，僅靠較少的人力幾乎做不到。

我們希望在現有的業務體系裡面，運維部門要實現這樣的運維目標？

第一個全面的性能管理。能夠提供對現在所有的設備和服務質量進行實時監測，並且提供動態閾值的告警。

第二個統一的資源管理。很多企業業務都上雲了，需要有統一的監控平台，可以把所有業務相應資源視圖抓取出來，便於我們對整體資源有一個合理的預估和分配，並從整體角度評估各個業務部門對資源的使用情況。

第三個及時的故障告警管理。我們發現有很多產品還不能做到完全及時的告警，告警發生後總是延時才能知曉，需要實時的準確的告警，減少延遲和誤報。

第四集中統一展現管理。把很多不同的監控子系統集成起來，這個在現在的企業裡面需求是很大的，藉助於各種工具，採集數據之後自動合成一個報表統一展現出來，方便管理。

我們關注的核心問題有：

第一我們是一個跨地域的平台，是多數據中心，我們希望有一個IT的綜合運維平台，來統一管理。

第二是深入監控並進行集中統一的可視化管理，提高效率。

第三就是有效的預防問題的產生，降低運維成本。另外就是問題出現後，能夠快速跟蹤定位，降低人力成本。

第四多維的報表為決策提供有力支撐，科學預判趨勢。

第五全局業務服務視角和平台化擴展以及大數據分析的融合，滿足企業對於業務高效和快速迭代的需求。

第六保護和優化IT資產。以前各個業務都是自己的一套系統，有自己的開發和運維人員以及監控系統，這對企業來說是重複造輪子了。現在上雲後，把原有的系統集中整合到雲上，通過統一的監控和資源管理最好的保護和優化資產。

要做好智能化運維之前，我們經過深入的分析，提了四個要求：

第一個是規範化。規範化就是儘可能的把操作規範下來，比如模板里是什麼基礎配置和安全基線，有一個規範化的標準。

第二個是可控性。就是能夠通過雲監控平台發現各個業務存在的瓶頸，包括資源瓶頸和性能瓶頸，對可能產生的問題可控可分析。

第三個是數據化。基於海量數據的決策分析，才能方便作出準確的判斷和科學決策。

第四個是主動性。從被動響應變為主動服務，主動發現問題，把問題消滅在萌芽中，在業務發生問題之前及時告知，這個感覺就不一樣了。

我們希望構建現代化和智能的運維管理模式，主要是以下5個方面，如下圖：

二、全景業務服務管理

在互聯網大爆炸時代，國家層面上也在提互聯網+、數字化轉型、智能化等等。我們的系統能不能快速響應，為業務保駕護航？

面向業務的IT服務管理主要有這幾個特點：

1、監控的粒度要細，能通過一個曲線捕捉到異常點。

2、面向業務管理和面向用戶管理。這塊要區分開來，在企業里用戶許可權分的是比較細的，什麼人可以操作什麼樣的業務，管理員可以管理哪幾類業務都有清晰的定位。

3、數據的全面和擴充性。數據只有全面才能進行科學的決策，很多時候如果看到的日誌不全，或者拿到的監控數據不準，在做決策的時候肯定就會比較貿然。比如數據中心某業務鏈路出現問題，是不是要切換？數據是不是還能保持一致？這個時候在沒有確定的數據來支撐你決策之前，你做決策時都會感到比較忐忑，猶豫不前。

建立以業務為導向的綜合監控平台，主要目的就是要統一展現、統一管理和統一調度。全鏈路監測，這個目的就是從訪問入口進來後一直到數據出去，每一個過程都要能監控到感知到。

從業務的視角進行IT基礎資源的管理與維護，一旦某個資源發生故障或問題，都可以從業務視圖中直觀地了解到這個資源的故障將影響什麼業務影響哪些服務，進而了解到影響哪些用戶。

資料庫慢了，CPU突然飆升了，這些地方這些資源突然發生變化了之後，影響到哪些業務呢？這時候就需要將監控資源視圖和業務關聯起來，這樣才能準確定位影響了哪些業務。

這個是問題的整體診斷和分析。

任何問題都需要採集相關的日誌和數據，才能科學全面的分析問題。

採集層需要把不同數據源的數據採集過來，中間層做一些性能分析，配置管理和預警分析、告警處理。展示層將分析的結果展示出來，也就是各種圖表，建立綜合的業務指標分析，方便根因定位和解決問題。

三、基於大數據平台的日誌分析和多維報表

基於大數據平台，提供日誌的採集和聚合處理，通過日誌關聯分析幫助準確全面定位提升效能和滿意度，智能預測和預警，為科學決策提供量化依據。

將採集到的網路監控數據、機房數據、伺服器和雲環境監控數據以及攝像頭報警數據集中起來，數據彙集之後生成PMDB性能管理庫，在根據業務應用的特徵，建立不同的模型進行相應的演算法分析。

根據不同的資源類來定義KPI指標，建模目的就是方便快速分析，為資源管理、告警管理、集中化展現等其他模塊提供數據分析模型的支撐。

數據採集有兩種類型，一種是被動的，一種是主動的。

採集業務相關指標，可以對數據進行預處理，做一些有效性的標籤識別，比如這個信息和指標是不是你關注的，對不友好的日誌進行格式化處理。

性能指標的計算，要跟業務進行協同，從業務的角度來定義。設置的

閾值，有些場景是固定的，也有的場景是動態的。固定閾值就相當於資源使用率，肯定有一個上限的。動態閾值像一些性能曲線，CPU的利用率、頁面響應、圖片載入等這些是可以使用動態閾值的，根據歷史數據來計算出這個動態閾值，某一時刻的歷史峰值，根據這些合理計算出在那個時刻到底需要多少資源。

根據上面的閾值會有一個報警的事件，任何事件產生都是基於時間的，故障的定位肯定也要基於時間找到相關的日誌和發生的事件。

事件診斷一直是運維領域一個很重要的工作，事件和時序的相關性不僅可以為事件診斷提供很好的啟發，而且在幫助我們進行根因分析時也能提供很好的線索。某個時間段出現的故障，都會產生一些相關的事件，對它們進行篩選和過濾是能夠詳細捕捉到故障和定位到根因的。

在事件診斷和處理中，是不是需要引入演算法，我覺得是有必要的，如果能提高效率和提高解決問題的能力，一切探索都是值得的。

也有一些運維界的朋友們花了很多時間和精力，去學習和研究演算法，我認為不必過於糾結演算法， 簡單了解一下開源的這些演算法，知道這些演算法的輸入和輸出是什麼，能解決運維中哪些實際問題，以及組合起來又能解決什麼問題，方便我們合理的應用它就可以了，這樣會對更快落地智能運維起到事半功倍的效果。

數據的匯聚處理就是把採集到的數據有機的關聯起來，壓縮、過濾形成標準化的信息。數據導入則可以通過全量的HDFS和增量的Kafka來實現。

基於大數據平台的多維報表，根據自己的需要，按照日、周、月來生成運維報告，發送給管理層的領導，這些數據是他們比較關心的，比較清晰的圖示出在這些時段發生了哪些問題，造成了多大面的影響，然後決定相關的資源是否進行擴充，相應的業務部署是否需要調整。

綜合展示比較關注的則是性能分析、容量分析和自動化配置。比如今年採購了500TB存儲，我用了多少，明年還需要擴容多少，業務增長量會有多少，這個都影響到企業的採購計劃。根據業務的實際進行評估，來推算出明年大概需要買多少TB的存儲。

四、IT監控管理平台發展

IT監控管理的發展大概有三代，從上世紀九十年代至今，第一代是以網路為中心，在這個時期咱們提供比較多的都是基於網路的監控和故障發現，帶寬管理和服務水平協議。

第二代監控就是以監控IT基礎設施為中心，看到比較多的就是主機、存儲、操作系統、中間件、資料庫等各類基礎資源的監控。

第三代監控以IT應用為中心，針對比較高度複雜的交易，需要實現面向用戶體驗和面嚮應用高可用性的實時監測和故障的智能診斷，運維人員必須高屋建瓴、全面謀劃，有能力提供一個全局性、高效健壯、標準規範、自動化的監控解決方案並加以實現。

五、故障管理及自治自愈

這是我們每天收到的告警情況統計，在沒有自動化和智能化之前，我和大家一樣心態是焦慮和崩潰的。

如何從錯綜複雜的運維監控數據中得出我們所需要的信息和結果，一句話就是分辨和精鍊，提取真正需要關注的信息，從而減少每天的告警信息量。

目標就是簡、智、深。

簡就是要確保業務和SLA服務級別，出現問題要及時響應、自動分析和優化，把處理的流程精簡和高效組合起來，讓問題匹配正確的場景，找到正確的人，在第一時間正確處理。

機器學習主要就是突出智，這個需要大量的數據來訓練，故障出現的形態是千奇百怪，對故障的歷史數據進行場景分類和標註，不斷用模式識別和數據來訓練機器識別和分析，然後讓機器自動準確判斷。

當然標註不能完全靠人，也需要通過機器來自動進行關鍵詞標註，而標註的合理性就需要人為進行判斷，然後再利用到機器學習上，這樣才能真正輔助我們做一些決策。

基於架構、工程師的經驗和概率來做到收斂告警事件，基於規範和分工產生告警事件發送到對的人，基於數據和模型來提高事件的處理能力。很多事件有的工程師處理的特別快，反之如果對這個故障不熟悉的人可能花費的時間就很長。這就需要構建一個策略知識庫，讓其他人來參考和學習，提高同類場景事件處理的能力。

智能運維的終極，實現的目標就是減少對人的依賴，逐步信任機器，實現機器的自判、自斷和自決。

技術都是在不斷的進步，AI技術將來會解決很多的一些需要花費大量人力和時間才能解決的事情，但是AI不是一個很純粹的技術，它也需要結合具體的企業場景和業務，通過計算驅動和數據驅動，才能產生一個真正可用的產品。

智能運維技術在企業的落地，不是一蹴而就的，是一個漸進和價值普及的過程。

我們可以看到，智能運維技術已經成為新運維演化的一個開端，可以預見在更高效和更多的平台實踐之後，智能運維還將為整個IT領域注入更多新鮮和活力，在未來發展和壯大下去，成為引領潮流的重要性力量！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！