2.1AIOps（智慧運維）

          在第四方物流資訊智慧運維平臺，管理主機快速增加，IT架構日益複雜，複雜的拓撲與不可靠的CMDB，讓運維繫統更加複雜多變，機器學習和大資料給了運維新的出路。智慧運維（AIOps）是人工智慧（機器學習）、網際網路領域知識、工程的交叉領域。網際網路領域技術和工程開發技術在此不贅述。智慧運維常用到的機器學習技術包括相關性分析、迴歸、關聯分析、聚類、決策樹、隨機森林、支援向量機、隱氏馬爾科夫、卷積神經網路、LSTM（Long Short Term Memory) 等等。這些演算法在各種（開源或閉源的）工具集中都有現成的程式碼實現。智慧運維的一個主要挑戰是根據具體需求評判應用哪些機器學習演算法，並適配或改造。

                                                                圖  第四方物流智慧運維平臺

                                                                            圖  智慧運維分析

     從技術上看，AIOps與大資料，雲端計算關係密切，而大資料與雲端計算的關係就像一枚硬幣的正反面。大資料必然無法用單臺的計算機進行處理，必須採用分散式架構。其特色在於可對海量資料進行分散式資料探勘，但必須依託雲端計算的分散式處理、分散式資料庫以及雲端儲存、虛擬化技術。大資料和雲端計算給了AI第二次生命。

   其實海量資料主要分成兩塊，一是系統建設技術，二，海量資料應用。系統建設現在主流的技術是HADOOP，主要基於mapreduce的分散式框架。在分散式系統出來之前，主要是集中式架構，如DB2，oracle。為什麼現在用分散式架構，那是因為現在集中式架構受限於IO效能，出來速度慢，如果又一種硬體技術，可以很快地處理海量資料，效能上能滿足需求，那麼集中式架構優於分散式架構，因為集中式架構穩定，運維壓力小。現在的集中式架構要麼效能達不到要求，要麼就是過於昂貴。

 而第四方方物流智慧運維場景產生的海量資料大體上可以分為兩類：一類是時序資料，例如：CPU，記憶體，磁碟等資料，主要反映系統當前以及歷史執行狀態；另一類是事件資料，例如:報警，異常，上線，變更事件，主要用於記錄發生事件詳細資訊

                                               複雜資料的儲存策略

智慧運維是相對傳統運維的一種升級和進化，智慧運維能夠實現業務系統的自動化故障智慧檢測，自動判斷哪些異常、哪有告警，從而能夠輔助管理者進行故障根源判斷和處理。幾年前一般的企業只有幾十個或者幾百個伺服器資源，而今天隨著雲端計算、虛擬化技術的發展，網際網路技術的廣泛應用，一個企業擁有幾千臺或者上萬臺伺服器資源也是常見的。這30-40倍的增長使得在運維層面的負擔變的更加嚴重。在監控層面要想獲得每一個伺服器的每一個指標更加困難。

     另一方面，業務系統複雜度也在增長，架構更加複雜，cache資料、非關係型資料庫、大資料架構、離線的資料處理、app、PC端應用等，這些以傳統監控方式一個一個配置已經不能滿足管理需求。隨著管理資源的數量和負責度增加，監控出現了太多的指標和圖表，人的精力是有限的，工程師規模卻沒有太大的增長。那麼如何從海量的指標中找到工程師關注的指標、關注的圖表，傳統的監控一個一個配置方式已經不能滿足需求。所以，今天的運維管理人員更需要智慧化的運維來幫助他們降低運維的壓力。

      AIOps的落地，將把日常的IT管理工作移交給擁有機器學習和自動化運維的智慧運維平臺，大大降低企業管理的時間成本和資金投入。而運維管理人員也可以從篩查海量告警資訊、執行重複性巡檢任務、人工判斷故障、手動解決問題的低效工作中釋放出來，專注於構建更加高效、高擴充套件的IT系統，支援企業的數字化業務發展，這也就是業界所倡導的“IT從運維到運營”之路。

        AIOps智慧運維平臺還能有效預測潛在的IT故障，並在無需人為干預的情況下提前解決掉這些問題，而應用系統故障率的降低，將有效提高資源的使用效率。這得益於機器學習和深度學習演算法在IT監控和應用效能管理系統中的持續積累，不斷記錄IT運維人員在不同場景下使用故障排除或修復基本問題的自動化工具的操作。當針對不同型號裝置、不同應用系統、不同的雲平臺的學習樣本資料足夠豐富時，AIOps智慧運維平臺就可以自動評估系統的健康狀態，如CPU使用率、磁碟吞吐率、裝置故障率等，如果發現了系統的異常活動，就能提前自動觸發相關運維操作。

      採用AIOps的能力不僅取決於IT監控系統的資料規模和自動化系統的可用性，還取決於人員和流程的一致性。服務商可以在很短時間內把AIOps智慧運維平臺部署到企業，但任何管理轉型都不是安裝一套系統那麼簡單，需要根據業務特點對人員和流程進行調整，而這往往需要更多的時間。

      要衡量AIOps智慧運維平臺在企業中的實施效果，可以重點關注兩項關鍵指標，平均故障恢復時間（MTTR）和事務（故障）處理數量，這兩項指標反映到客戶滿意度上，就是AIOps的價值。

智慧運維（AIOps）常見演算法應用包括如下：

(1) 指標趨勢預測;通過分析指標歷史資料，判斷未來一段時間指標趨勢及預測值，常見有Holt -Wintors、時序資料分解、ARIMA等演算法。該演算法技術可用於異常檢測，容量預測、容量規劃等場景。

    (2) 指標聚類:根據曲線的相似度把多個KPI聚成多個類別。該演算法技術可以應用於大規模的指標異常檢測:在同一指標類別裡採用同樣的異常檢測演算法及引數，大幅度降低訓練和檢測開銷。常見的演算法有DBSCAN, K-medoids, CLARANS等， 應用的挑戰是資料量大，曲線模式複雜。

   （3）多指標聯動關聯挖掘:多指標聯動分析判斷多個指標是香經常一起波動成增長，該演算法技術可用於構建故障傳播關係，從而應用於故障診斯。常見的演算法有Pearson correlation, Spoarman correlation, Kendall corrolation特，應用的挑戰為KPI種類繁多，關聯關係複雜。

 （4） 指標與事件關聯挖據 ：自動挖據文字資料中的事件與指標之間的關聯關係(比如在程式A每次啟動的時候CPU利用率就上了一個臺階）。該演算法技術同用於構建故障傳播關係，從而應用於故障診斷、常見的演算法有Pearson  corrolation, J-measure,Two-sample test等, 應用的挑戰為事件和KPI種類繁多，KPI測量時間粒度過粗會導致判斷相關，先後，單調關係困難。

  （5）事件與事件關聯挖掘：分析種常事件之間的關聯關係， 把歷史上經常起發生的事件關聯在一起。該演算法技術可用於構建故障傳播關係，從面應用於故障診斷，常見的演算法有FP-Growth，Apriori，隨機森林等，但是前提是異常檢制要準確可靠。

  （6）故障傳播關係挖掘，融合文字資料與指標資料，從於上述多指標聯動關聯挖掘，指標與事件關聯挖掘、事件與事行關聯挖掘等技術。從tracing推匯出的模組呼叫關係圖。輔以伺服器與網路拓樸。構建元件之間的故障傳播關係。該演算法枝術可以說用於的故障診新。其有效性上要取決於其基於的其他技術，

   第四方物流資訊平臺的許多運維場景通過無法直接通過基於通用的機器學習演算法以黑盒的方式解決，因為需要一些面向AIOps的演算法技術，作為解決集體運維場景的基礎。有時候一個演算法技術還用於支撐另一個演算法技術。

2.3 第四方物流資訊平臺系統架構的概念

第四方物流資訊平臺是將新一代資訊科技應用於物流業中，實現物流的自動化、視覺化、可控化、智慧化、網路化，從而提高資源利用率和生產力水平的創新服務模式。由於物流業與民生、工業生產和經濟發展高度相關，新一代資訊科技在物流領域的應用效果明顯示範性強，因此智慧物流備受政府部門關注。預計將成為未來十年地方政府和企業關注和發展的重點領域。

                                                    圖  第四方物流資訊平臺

第四方物流資訊平臺IT資源從幾十到幾百臺上升到萬級甚至是十萬級，監控本身每天可能產生的資料就是幾十T到幾百T，如何把這些海量的資料採集和計算儲存下來，並且把這些海量資料給使用者展現出來，從而進行一定分析，為管理提供決策，這是傳統監控系統很難解決的。隨著監控指標的增加，帶來的就是報警的增加。假設每天傳送3W-5W條簡訊、每天郵件報警量50W-100W，幾百個工程師如何處理過來，工作負荷無緣無故增加。更新的基於大資料的智慧監控方式可以解決，把相關度更高的告警聚合到一起，或者把重複的告警不傳送，把最需要關注的告警和最需要的故障資訊推送給工程師，這些需要通過大資料的相關性演算法、聚合的處理能力來實現。監控系統有問題發現的功能，同時也要具備輔助工程師定位、處理問題的能力，傳統的監控系統指標採集和圖表展示。在人力經驗和精力都無法滿足的情況下我們希望智慧運維繫統能夠自我診斷，從服務過去的第四方物流資訊平臺運維資料中自動識別故障特徵，從而能夠更準確的識別和診斷故障。

第四方物流資訊平臺智慧運維其實還有很多領域可以突破，例如資料視覺化技術讓開發、運維人員更加直觀的處理問題；利用基於大資料預測、預警的能力來實現故障預判，在故障發生前就提前進行預判，從而提升業務系統可用性；利用大資料的處理能力，採集處理更多的服務端的資料，這樣使得監控運維的資料資訊更加完整，形成全方位的運維資料覆蓋，實現使用者、服務、計算資源的無死角管理。

以下是第四方物流資訊平臺的架構

目標群體：系統日誌、伺服器、容器、系統軟體執行指標

日誌架構：ELK (Elasticsearch+Logstash+Kibana+Redis)

監控架構：GPE (Grafana+Prometheus+Exporter+Consul)

ELK由Elasticsearch、Logstash和Kibana三劍客組成，當然了以上是最基本的元件，為了使架構流程更加豐滿，我們加入了Redis做緩衝佇列，配置了sendmail做異常日誌告警。

ElasticSearch是一個基於Lucene的搜尋伺服器。它提供了一個分散式多使用者能力的全文搜尋引擎，基於RESTful web介面。它的特點有：分散式、零配置、自動發現、索引自動分片、索引副本機制、restful風格介面等。

Logstash資料分析工具，它可以對系統生成的的日誌進行採集、分析，儲存。2013 年，Logstash 被 Elasticsearch 公司收購，ELK Stack 正式成為官方用語。

Kibana是一個開源的分析與視覺化平臺，用來搜尋、檢視儲存在Elasticsearch索引中的資料。

工作流程：

logstash(shipper) 實時監控並過濾收集每個服務的日誌資訊。

logstash(shipper) 把收集來的日誌(INFO 、DEBUG 、RROR 、WARN等)分別傳送到Redis。

logstash(indexer) 按照日誌分類分別從Redis讀取日誌資訊併發送給ElasticSearch

logstash(indexer) 過濾出RROR日誌通過郵件或者其它webhook方式告警開發運維人員。

Kibana讀取ElasticSearch資料結合自定義搜尋進行頁面展示。

2.2 ISO 20000和SLA

ISO 20000是面向機構的IT服務管理標準，目的是提供建立、實施、運作、監控、評審、維護和改進IT服務管理體系(ITSM)的模型。建立IT服務管理體系(ITSM)已成為各種組織，特別是金融機構、電信、高科技產業等管理運營風險不可缺少的重要機制。ISO 20000讓IT管理者有一個參考框架用來管理IT服務，完善的IT管理水平也能通過認證的方式表現出來。

ISO20000標準著重於通過“IT服務標準化”來管理IT問題，即將IT問題歸類，識別問題的內在聯絡，然後依據服務水準協議進行計劃、推行和監控，並強調與客戶的溝通。該標準同時關注體系的能力，體系變更時所要求的管理水平、財務預算、軟體控制和分配。

 SLA(Service Level Agreement)即服務水平協議，指IT服務提供商和客戶之間就服務提供中關鍵的服務目標及雙方的責任等有關細節問題而簽訂的協議。 首先，SLA的實施，對服務的提供者（包括第三方服務供應商）和服務的使用者雙方都澄清了一些有關服務質量的責權，把體現QoS(Quality of Services)服務質量的指標進行量化，在一定程度上避免了雙方對服務質量的標準的歧義理解。因此SLA的實施，對澄清雙方的責權是有利的。     另外，SLA過程中的一個行為，就是要把承諾的服務品質進行量化(QoS服務質量的指標)並定期的統計、分析、報告，進行透明化管理。儘管定期給客戶提供系統執行的實際值，並主動報告“SLA違例”的情況的這種做法可能因為某些SLA違例帶來一些收入上的少量損失，但有助於提高服務質量，提高服務提供商與使用者之間的相互信賴指數，提高客戶滿意度。 

重大故障（P1）：系統重大告警；裝置停機；控制板、儲存板等系統板卡出現硬體故障；系統超過50個或10%以上的使用者無法正常工作；30%中繼路由失控；系統自動重啟兩次或以上；電源故障；電腦話務員故障重大故障發生時，提供7*24*8小時備件服務。

緊急故障（P2）影響系統話務臺或其他重要部位使用者。VIP人員話機故障，如總裁/管理總監/執行總監/總經理/高階經理等呼叫中心座席分機故障；錄音系統不能正常工作；CMS不能正常工作；計費系統不能正常工作；語音郵箱不能正常工作。

一般故障（P3）一般故障指重大故障及緊急故障以外的其他故障。