1、BAIOPS-業務智能運維
智能運維（AIOps-Algorithmic IT Operations基于算法的IT運維）是人工智能技術在IT運維領域的運用，引用Gartner 的報告的一段話“到2020年，將近50%的企業將會在他們的業務和IT運維方面采用AIOps，遠遠高于今天的10%”，最近2-3年智能運維的概念隨處可見，各大互聯網公司、傳統IT公司、金融業等都在談他們的智能運維設想，同時也有人談AI色變，覺得人工智能只是一個愿景，要落地很難。其實AI已經不是一個新的概念了，百度、微軟、谷歌等公司早就在10幾年前開始自己的人工智能布局了，到現在均已成為人工智能行業的領跑者了。
話不多說，人工智能那么強大，應用場景十分的廣泛，當然也包括運維領域，而且面向業務的運維更是運維發展的熱點趨勢，下面我就和大家就“面向業務的智能運維體系建設的探索與實踐”這個話題發表下我的個人見解。
2、傳統運維-痛之又痛
傳統的運維中，存在著諸多痛點：
（1）被動低效的運維難以保證業務連續性
運維人員往往扮演著事后“救火”的角色，待事故發生后才去處理；
數據分散在多處，出了故障無法快速修復，業務連續性難以有效保障；
隨著業務復雜性不斷提高，人工運維的成本呈指數級增長。
（2）缺乏統一的運維監控體系和技術工具
針對不同運維實體的煙囪式的運維工具，功能重疊、難以整合；
運維的自動化程度偏低，運維腳本泛濫，層次化、模塊化程度不足；
監控、運維、告警平臺林立，各成體系，缺乏統一化體系。
（3）海量的運維數據的價值無法充分挖掘
傳統運維系統收集了大量的運維數據，但是卻缺乏有效的手段加以分析和利用；
運維數據的利用僅限于簡單的可視化和淺度的分析上，缺乏縱向數據的關聯挖掘，無法快速定位故障根因；
固定式的閾值告警造成了大量的誤判和漏判，而且人工調整閾值的方式也比較費時費力。
（4）缺乏全方位端到端的運維監控手段
大部分的運維監控僅停留在針對主機、網絡的層面，忽略了業務層面的識別手段，故障的發生無法從最直接的業務層面得以發現，產生預警；
性能管理大多停留在服務單應用性能的管理和分析上，無法提供端到端的掌控。
3、業務智能運維的切入點
針對上述這些傳統運維中存在的痛點，智能化的運維出現必定具有劃時代的意義，智能運維系統的設計可以從如下幾方面進行展開思考：
（1）面向業務維度實現異常檢測
業務運維是運維的大趨勢，需從最復雜的業務維度入手，根據業務維度的指標（如PV、響應時間、錯誤率、GC等）上的異動進行異常檢測，提前預警；
（2）提供業務全局關系視圖
業務應用維度的復雜性是運維過程中最高的，往往是二線和三線運維之間界限最模糊的區域，所以智能運維可以先解決的就是向用戶提供全面、清晰的業務關系視圖，讓運維人員對業務應用的掌控得心應手；
（3）KPI可視化與下鉆定位
KPI指標可以通過豐富的可視化手段展示給運維人員，業務系統的故障可以清晰的體現在可視化終端，同時支持詳細的下鉆手段，直至定位到發生故障的環節，甚至代碼段；
（4）采用動態閾值思想的異常檢測
避免傳統固定閾值告警的弊端，引入機器學習算法來進行閾值動態化的異常檢測效果；
（5）重視故障的全流程管理
故障發生時，可以提供一定的手段將業務層面的KPI異常與引起故障的原因聯系起來，支持手動下鉆之余還可以自動定位和關聯；
（6）立體化監控體系的建設
覆蓋從資源、平臺層、應用監控和微服務調用鏈的立體化的運維分析能力。
4、業務智能運維體系架構
4.1智能運維核心要素
智能運維體系架構的建設應該考慮如下因素：
數據
我們要搭建智能運維平臺，首先要數據驅動，數據驅動下要做好以下幾件事：
海量數據存儲：運維數據的量級是億級、TB甚至PB級別的，所以存儲系統一定要具備高容量和擴展性；
數據多樣化：運維過程產生的數據多種多樣，如應用產生的性能數據，服務器基礎監控產生的CPU/IO/Net數據，服務間調用鏈數據、日志數據等，那么需要針對不同類型數據進行區別化的存儲結構的設計，保證數據存儲的擴展性，同時建立數據之間的關聯支點；
分析能力
分析能力是智能運維平臺的核心，可以應用大數據+機器學習的分析能力，結合成熟的開源分析算法實現基本的數據分析，再結合具體的應用場景，做出一些適應性改造或匹配來實現相對較好的分析效果，千萬不要只想著做出來一個分析平臺來，這個平臺做出來不是難事，關鍵在于這個平臺在運維領域沒有實際意義。
運用起歷史數據的價值，且可以有效識別出數據的各維度的規律，如周期性、趨勢等，而且分析能力必須結合應用場景，判別相對適合的算法模型來訓練數據，方能保證預期的設想。
分析能力可以隨著時間的推移不斷的演進，可以將新數據的特性帶入到模型中來，以不斷提高算法的準確度。
4.2智能運維體系架構
（1）用戶層：
面向業務的智能運維面向的用戶，不光光是面向于傳統的運維人員，此外，業務監控人員、業務部門主管、客服人員都可以在系統上找到自己所需要的數據、看到自己所想看到的東西；
（2）視圖層：
提供WEB端豐富的可視化視圖、大屏方式的業務狀態視圖、以及滿足移動辦公需求的手機端APP；
（3）服務層：
業務智能運維將提供給用戶業務視圖服務、拓撲服務、性能KPI服務、運維分析服務、告警服務、報表服務以及系統服務等，為用戶提供豐富的監控、分析和告警視圖功能。
（4）核心能力層：
智能運維系統的最關鍵部分，可以分為三個較大的模塊“智能監控”、“智能分析”和“智能告警”。
實現針對各個層面的監控覆蓋，包括用戶體驗的監控、應用性能的監控、中間件監控、基礎設施的監控，只有收集了全面的數據，才有可能從數據中尋找關聯，從關聯中發現規律，豐富運維知識庫。
智能分析：
智能分析為整個核心能力層中最核心的部分，該部分應該涵蓋離線算法的訓練模塊和在線實時分析模塊
離線算法訓練模塊要根據歷史數據來以離線的方式訓練和修正算法模型，然后生成的算法模型就類似于一個個的[if else]判斷形成的規則組合，當最新的數據輸入到算法模型，就可以實時的給出推測，用于預測、異常檢測、故障定位等場景，這里面當然就需要機器學習和深度學習的算法來撐場面了。
在線實時分析模塊要實現實時的算法分析，并不依賴于歷史數據所訓練出的離線模型，而是進行實時的計算，這里則需要大數據的實時計算技術了。
智能告警：
智能告警需要可以有效的遏制“告警風暴”，這個可是告警系統中必須面對的問題，那么需要提供較高效的分析算法，實現告警的自動歸類、自動消除，那么歸類中最合適的方法就是尋找告警之間的關系關系，將相近的告警合并為一條發送，避免告警風暴。
智能告警還可以動態調整告警短信/郵件發送的頻率和周期，還有告警通知對象的智能配置，保證運維人員處理告警的專注性，不會被突如其來的海量告警所淹沒。
5、業務智能運維典型應用場景和關鍵設計
5.1數據的采集
（1）業務層數據的采集
包括接口響應時間、調用次數、服務間調用關系、時延、慢SQL、JVM內存消耗、以及線程棧信息，上述數據的采集可以參考Google Dappe的思想實現，其中一款較好的開源軟件就是pinpoint。
pinpoint運用JavaAgent字節碼增強技術實現應用服務端數據的采集，且無侵入式的設計，使用方便，無需更改業務代碼。可以內置支持JAVA程序內幾十種協議交互的兼容，如http、okhttp、mysql、oracle、postgresql、dbcp、cubrid、kafka、rabbitmq、springboot、log4j、logback、redis等。
hbase 實現海量數據的存儲，通過部署在業務遠端的agent通過UDP+thrift的方式將應用采集的數據傳輸到collector，經過處理后實現hbase的落存。Web UI實現監控的可視化。
通過pinpoint進行鏈路追蹤的原理圖，可以簡單的理解為在一次交易過程中，貫穿的整個分布式系統的各個環節內都維持著一個唯一的transactionid，且允許記錄上下文環節的spanid，從而實現鏈路信息的洞悉。
且pinpoint允許開發者自定義開發插件，實現更多協議的監控支持，如activemq、zookeeper、consul等。
不過pinpoint的功能如此強大的同時，還需要我們做適當的優化，如：
Agent發送海量的udp數據到collector，很有可能遇到網絡和collector的阻塞，那么，這個時候可以在agent和collector之間加一層kafka實現消息的緩沖，提升系統穩定性。
Pinpoint沒有用戶權限體系，需要我們自己實現。
可以通過參數自定義的方式來指定實際需要采集的指標項，避免agent多余的性能損耗，降低系統負載。
（2）關聯數據的采集
關聯數據包括基設施數據和中間件數據。
首先，基礎設施數據如服務器的性能狀態的數據，包括CPU、磁盤、內存、IO、負載等維度各個參數的獲取，您可能首先想到的是zabbix，那么zabbix確實功能強大，但是“殺雞焉用牛刀”，上述CPU/磁盤/內存等幾個參數就是我們隨手敲行代碼就可以搞定的事，只不過做成定時任務即可，所以我們不用zabbix，轉向輕量化的開源手段，其實TICK數據采集框架您可能都聽過，那么我們模仿TICK，通過TIG（Telegraf+influxdb+grafana）框架也可以輕松搞定了。
Telegraf是一種輕量級的采集框架，支持秒級別間歇的采集粒度，對服務器的資源占用很小（不到3%）；
Influxdb是一種高性能的時序數據存儲引擎，可支持百億級別的時序數據的存儲，而且內置強大的連續計算、API功能，你可以輕松的實現數據的匯聚和外部調用；
Grafana是一款基于JS的前端可視化引擎，支持豐富的dashboard組件，如圖表、儀表盤、表格、清單等，你可以利用它輕松實現各種高大上的性能監控頁面，另外grafana和influxdb的兼容性也異常的友好。
同樣，常見的Paas和Daas層中間件，如nginx、apache、zookeeper、docker、mesos、ZFS、Elasticsearch、mysql、mongodb、postgresql、sql server、rethinkDB、influxdb、couchDB、redis、memcache、rabbitmq等的組件的監控也都可以通過TIG框架實現監控。
至此，我們已經可以實現應用層數據和其關聯數據（Iaas層、Paas層）的集中采集和匯聚，那么有了數據，能做的事情簡直太多了。
5.2業務層面的精細劃分
欲建立面向業務服務維度的監控體系，首先需要針對業務服務做出分層次的劃分，即對業務監控對象的管理需要建立體系，智能運維產品的業務服務管理體系結構如下：
②③④層，專注面向業務維度的監控的同時，更要對業務層面進行精細化分層，比較容易想到的辦法就是建立系統、服務、實例三層的業務監控體系。
針對系統、服務、實例做一個概念的普及：
系統：完成某一類完整需求的系統體系，如OA系統，系統是一個比較抽象的概念，一般由一個或多個運維人員來管理
服務：系統的下一層模塊，即完成系統內某一個完整的相對獨立功能的模塊，如個人信息管理服務、薪資管理服務、流程引擎服務等；一個服務一般部署為一個集群，包含多個應用實例（如tomcat）
實例：屬于一個服務集群中的一個具體的應用實例，一般一個服務集群會部署多個實例到不同主機上，如薪資管理服務實例一、薪資管理服務實例二，實現負載均衡。
在這三個層次上進行性能的監控，實現了業務應用從上到下三層的數據關聯，服務運維人員可以更深入的掌控系統業務的關聯狀況。
那么我們是否可以針對系統、服務、實例分別進行性能監控呢？如果發生故障，就可以尋根溯源，舉例：如果一個服務層的指標（如服務整體平均響應時間發生偏高的異常），那么必定是由其下的一個或多個實例導致，現在我們去查看每個實例的性能信息，通過皮爾曼相關系數，發現性能曲線和服務性能曲線最近的實例，就是異常實例，進而可以針對該實例的Top N請求進行下鉆分析就可以得到故障所對應的代碼行，問題就可以解決了。
上面所建立的系統服務實例的關系，本身就是利用了業務應用運行時本身就存在的關系，那么為何不利用起來呢，到這里還沒用到高大上的AI、機器學習呢。
5.3故障可視化與故障重現
故障可視化
當發生故障時，可以在指標的運行圖譜高亮顯示該異常點，也是可視化工作中必須的，正如如下圖：
系統識別到了“響應時間”的異常，當前時間點的異常指標為11ms，同時一個友好的智能運維系統會把該時刻系統其他方面的指標也展示出來，運維人員可以直觀的看到不同曲線之間的關系，并且圖中每一個坐標圖的右上角都展示了該指標與異常指標之間的“相關系數”，并且按相關系數絕對值倒序排列，相關系數絕對值越接近于1，那么就越有可能是問題的直接或間接原因。
故障重現
另外當業務系統的一次請求發生了錯誤，如果我們可以提供手段將該次請求的過程進行一次重現，對于運維人員的排錯支持也“將是極好的”。
可以對一次應用的請求進行回放，每一個環境執行了多長時間都可以一目了然。
5.4異常檢測
說到異常檢測，應該是業務智能運維領域中的一個最常見的場景了，異常檢測的方法很多，本篇中會重點的介紹一下我的見解：
（1）傳統的異常檢測方法
傳統模式下完全基于人的主觀經驗，也即基于固定閾值的異常判斷，如 CPU usage高于80%就告警，這種方式適配性是很差的，需要針對不同的場景設定不同的閾值，甚至同一個業務不同時間段的閾值都是不一樣的，大量個性化的配置要求，對于運維人員來說是十分崩潰的。
后來就出現了一定的改進，如3-sigma算法，是根據正態分布的概率，自動的調整告警閾值，是的，告警閾值的配置不用人工進行，一定程度上提高了運維效率。但是，該類的算法機器容易忽略指標的周期性和趨勢性，造成誤判的問題也很常見了。
（2）基于統計學和機器學習的異常檢測方法
總結前面的異常檢測方法，可以概括為兩點：人工運維工作量大、算法適配性低下。其實歸結為一句話，就是動態閾值怎么評定的問題。
這個時候就比較適合引入機器學習了，比如基于指數的三次平滑算法、基于分解的傅里葉/小波分解算法等，可以有效的識別出指標的周期性、趨勢性，可以快速識別出一些尖峰（spike）異常。
另外自回歸移動平均模型（ARIMA算法），對于穩定的時序數據的異常檢測是非常有效的，該算法也非常適合用作時序數據的預測場景。
還有基于深度學習的循環神經網絡 RNN算法和長短期記憶網絡LSTM算法，比較適合處理和預測時間序列中間隔和延遲相對較長的重要事件。
基于機器學習的眾多算法，都可以大大的提高運維的效率，發現人工難以發現的問題，提高預警的及時性。
（3）異常檢測模型優化
上一小節提到的各類機器學習算法，雖然都功能強大，但是往往都有一定的局限性，那么我們在對具體的一個場景指標（如響應時間）做異常檢測的時候，我們到底選哪個算法呢？
方法一：這個問題可以通過“自動模型選取”方式來解決，即采用多個算法同時運行，然后通過投票的方式抉擇產生最終的結果。
舉個例子，針對“響應時間”指標進行異常檢測，采用同比、環比、ARIMA、LSTM、KNN、高斯共5個算法同時進行異常檢測，當其中的一半（即>=3）的算法判定為異常時，方認為該時刻的指標是異常的。
方法二：在方法一的基礎上為每個算法加入權重值，5種算法初始值均為20（總合為100），當一次異常的判斷后，比如算法1/2/3都判定是異常，算法4/5都判定為非異常，那么最終結果為判定為異常，系統向運維人員發出告警，當運維人員在平臺上通過指標橫向對比、請求下鉆、事件挖掘之后發現該時刻的指標確實為異常，那么運維人員會將這個告警處理掉，那么此時后臺就會默認向投票正確的算法的權重傾斜，為其權重加1，同時為投票錯誤的算法權重扣分（但總分仍保持100分）；而如果運維人員發現該告警是誤報，則會在平臺上反饋“誤報”，則后臺會向投票為非異常的算法權重傾斜，為每個算法權重加1，同時為投票為異常的算法權重扣分（但總分仍保持100分）。如此經過長時間的不斷調整，算法組合就越來越接近于準確。
（4）答疑解惑
不過有朋友可能會遇到如下問題：
Q：如果我要檢測的指標剛剛上線，我根本就沒有離線的訓練模型怎么辦？
A：那就初始階段不利用離線模型的算法，先使用ARIMA、同比、環比、KNN這類的算法跑起來，等待歷史數據足夠了生成離線模型之后，再以同等權重（取得和現有算法權重的平均值，再進行100分支均衡）的方式加入到算法集合中。
Q：我使用這么多的算法來進行異常檢測，對于前端告警規則配置的時候來說，我該怎么去選擇我去使用哪種智能的算法呢？
A：異常檢測的目的就是要識別異常并發出告警，那么在告警規則出進行配置，選擇智能化的方法來檢測異常的思路是正確的，但是沒有必要讓普通的運維人員來看到我們所提供的眾多算法，還有算法邏輯，對于他們來說我們只需要讓他們選擇諸如“智能告警”這樣的選項就好了，后面的算法選擇交給專業的“運維算法工程師”來搞定就好。
Q：有了“智能告警”之后，是不是固定閾值告警就不需要了呢？
A：并不是，智能告警解決的是無法直觀、簡單判定故障的場景，但是對于錯誤率、CPU利用率、磁盤剩余量這些基本場景時，還是可以使用閾值告警的，甚至做分級閾值告警（如一般告警、重要告警、嚴重告警等），這些基本的閾值告警發生后一般都是比較嚴重的情況，都是需要處理的；而且，這些告警信息匯聚起來，也可以作為業務層面異常故障定位的參考依據，因為很有可能這些固定閾值觸發的告警就是業務層面故障發生的根因。
（5）算法訓練和模型管理平臺
好了，長篇大論了半天，我們似乎還忽視了一個關鍵的問題，那就是離線訓練的模型是怎么來的，怎么用起來，怎么選算法，怎么調優，算法一定好用嗎？
帶著這一系列的問題，我們可以想象的到，一個離線算法訓練和模型管理平臺是十分必要的，這就是“運維算法工程師”所需要使用的平臺了，這個平臺至少要實現如下功能：
算法如何選擇
算法的好壞可以評估
算法最好經過測試后才可上線
離線算法訓練管理平臺的設計可以參考如下模型：
該平臺可以獲取需要檢測的指標，展示過去一段（如一周或一天）時間的曲線；
特征分析器會根據預設的特征組合（事先定義好針對曲線可能的各種特征的識別判定方法庫），提示出該指標的曲線對于各類特征（如上升趨勢、周期性、隨機性等）的支持度，支持度越高代表著該指標越具有什么特征；
然后算法推薦器會根據預設的特征-算法組合（事先定義好各種特征所適用何種算法的映射庫），推薦出建議的算法集合（可1可多），當然也允許“運維算法工程師”在查看了第一步的曲線后，自定義選擇算法庫。
下一步就將通過前面算法推薦器推薦的算法或運維算法工程師自定義的算法組合進行模型的訓練，將生成的臨時模型保存起來；
然后，采用真實的線上數據來跑這個臨時模型，會得到對應的告警；
當運行一段時間（如一周或一天）后，將臨時模型發出的告警和線上模型產生的告警進行對比，去掉重復的部分，剩余部分通過運維工程師的標注和反饋，得到兩個模型的誤報率（當然也可以采用漏報率），若臨時模型的誤報率低于線上模型，則認為模型是有效的，可以進行發布環節，該臨時模型替換線上模型，進入生產。
注：臨時模型和線上模型的對比如果無法通過運維工程師的評估快速得到的情況下，也可以采用比較通用的算法評估方法來計算得出，不過最好的手段就是“利用運維工程師的判斷”。
5.5關聯分析
關聯分析一般會作用在故障定位和告警歸集兩個差勁
（1）故障定位
基于關聯關系的基礎可視化輔助
在針對系統的異常進行有效的檢測后，極大的縮小了故障的范圍，如將故障縮小到了某幾分鐘內，然后將相關的其他指標曲線和故障曲線同時可視化展示，則可以輔助我們深入數據進行問題的定位：
理論依據：當某一個維度的指標發生異常時，那么相關的其他指標也極有可能一定程度上體現出正向或反向的波動，如果可以將多個疑似相關指標的曲線在一個圖上展示，并提供格線比對功能，那么相比于傳統的翻閱日志看log的情況，將會更快的定位到問題的原因。
落地場景：如上圖所示，某服務器上某服務實例在10:00左右發生了響應時間嚴重變慢的情況，經過對相同服務器的各項指標分析，可知當時系統CPU占用在同一時刻上升，且內存的空閑率也大幅下降，但是實際的業務訪問量并沒有飆升，說明并非業務繁忙導致，疑似服務器硬件問題所致；同時在針對部署在服務器B上的相同實例的指標進行對比，發現各項指標并無明顯波動，且和服務器B上正常指標類似，所以可以確定是因為服務器A的硬件問題導致，完成故障初步定界，繼而再去排查服務器的相關指標，便可迅速定位問題。
基于多維度數據的異常診斷分析
理論依據：通過貢獻度和一致度評判問題根源（如ERROR數量維度）
貢獻度：即各維度異常數與總異常數的比例
一致度：即構成該維度的子維度的異常程度的相似度信息。
那么貢獻度越高、子維度的異常相似度越高，則該維度為根因維度的可能性越大。
因此，可以將數據的各維度展開，分別計算各維度的貢獻度、一致度兩個特征，構建評估參數P=貢獻度/一致度，該值越高，則該子維度為根因維度的可能性越大。
落地場景：當發現某服務（如充值服務）的錯誤率告警突然大幅增加時，傳統運維人員往往無法快速定位，甚至問題的定界都需要大量的時間，如果運用智能運維產品，可以將該服務的所有6個實例上進行3個錯誤共6*3=18中維度上進行分析，利用上述理論中的評估參數列出排名前N的組合，迅速將問題范圍大幅縮小，提高排查的效率。
可以定位到實例4的404錯誤是錯誤數的主要原因，可針對性進行排查
（2）告警歸集
基于關聯挖掘的告警分析
采用機器學習算法實現告警的關聯挖掘，進而實現告警前的合并優化，與告警后的數據分析，反哺合并策略。
理論依據：歷史上每次某一個告警總是伴隨著另外一個告警的出現，那么可以懷疑兩類告警之間存在必然聯系，甚至因果關系，所以可以考慮合并該兩類告警，并積累在運維知識庫內，隨著歷史數據的豐富，告警合并的準確性將不斷提高。
落地場景：在歷史數據上，A實例的策略R1和B實例的策略R2經常同時報警，那么A實例的策略R1和B實例的策略R2就極有可能存在關聯，經過一定的置信評級，就可以合并在一起發送。
注：置信度是針對一條關聯規則A告警->B告警而言定義的，代表了A告警導致B告警發生的可能的概率
智能告警體系下充分利用從業務到主機的縱向數據關聯，實現告警的聚合與收斂
依據：將運維對象劃分為不同的層次
業務角度：服務/實例/告警類型
部署角度：機器/機房
同一角度同一層次同時刻的告警，很可能存在著一定聯系，故而可將這些告警合并。
落地場景：話費查詢服務的信息港機房內服務1的A實例在發生進程丟失告警，同時該服務在信息港機房的服務1的B實例上也發生了進程丟失告警。這兩個告警屬于同一個機房的同一個服務的同一個策略（進程監控策略）下的告警，且為同一層次，因而可以實現收斂。
小結
上述基于關聯關系實現了故障輔助定位和告警的智能歸集，其實還有很多落地的場景，如根據事件依賴關系構造動態事件概率模型圖，如果有大量的歷史數據做分析，就可以充分的識別出各類事件之間的因果關系，這些因果關系就是最寶貴的運維知識庫。
5.6負載均衡優化
同時，智能運維系統也將輔助軟件負載策略的優化，通過針對集群的全面監控和分析，在負載層做出更新時，可以及時的發現集群整體的健康劣化的狀況，及時發現負載策略變更導致的問題，并向負載層軟件上報問題或針對負載策略優化的建議，以更加智能化的手段提高系統的高可用性和效率。
輔助負載優化常用場景包括：
相同負載下某主機的硬件指標告警，則可以考慮將其上應用轉移到其他低負載主機上，或降低負載均衡器的分配權重，達到所有主機整體健康；
當發現某主機上應用響應變慢，并且將會發生故障時，負載均衡的tcp探查無法發現，運維系統可以實現事先預警，并定位事故原因（一般為硬件或負載均衡器分擔錯誤問題），同時上報負載均衡器，事先負載重分等止損措施；
灰度發布過程中，可以通過智能運維產品監控新版本的性能情況，如可及早發現新版本應用性能較差或者存在錯誤警告，則可以及時上報灰度發布系統，及時止損，或觸發自部署節點的回滾自愈操作。
5.7日志分析
日志分析的作用，往往會體現在如下幾個場景：
（1）針對業務日志進行業務的多維分析
如通過CDN的日志，實現用戶的行為畫像，也可以實現故障分布的拓撲視圖；
（2）針對于日志中出現的各類關鍵日志
可以提煉出關鍵的事件來，這些事件如果和前面的業務異常所關聯起來，就可以實現業務異常所對應的根因事件溯源；
（3）利用諸如ELK這樣的平臺
針對分布式的日志進行匯聚和索引后，就可以發揮和業務層性能采集一樣的作用，將日志進行解析后，同樣是是一列一列的性能指標，而后再來做異常檢測還是可以的；
（4）利用日志做運維審計與合規
也是一個智能運維的典型場景。
6、智能運維的最高境界-故障自愈
針對于故障自愈應該以故障定位準確基礎之上開展的，需要逐步推行，在此我就結合幾個場景來聊一聊故障自愈的設計方案（按照云計算體系進行分層描述吧），以輔助落地：
（1）Saas層：
服務4**/5**錯誤：直接重啟進程后再檢測。
服務性能緩慢：排查相同集群服務是否均發生劣化，如僅此節點劣化，可采取流量分擔方案；如全部節點均劣化，可采取自動擴容方案。
頻繁GC：可按需增大JVM內存分配后繼續監控。
（2）Paas和Daas層：
Spark executor性能明顯劣化：可在下次任務開始之前更新–executor-memory
Db阻塞連接數激增：可斷開超過設定閾值（如2分鐘）的連接
Docker性能下降：新建docker分配更大內存，對現有docker進行替代
YARN資源分配失敗：判斷YARN資源情況，如果占用已滿，進行動態擴容
（3）Iaas層
磁盤滿：調用清理文件腳本實現清理，并釋放進程資源占用
磁盤不可見：嘗試重新掛載，如無效后直接將告警轉發給硬件維護人員
內存不足：嘗試清理服務器page cache等
輔助優化的方案：當發生故障后，并不一定需要立刻觸發自愈操作，如突然的網絡抖動，引起服務報錯、性能緩慢的故障，很有可能過若干分鐘即可自行恢復，此類則不需要立刻修復，那么優化后的方案可以參考如下的思路：
首次發現故障暫不觸發自愈操作，待連續5次出現同樣故障，觸發自愈操作；
采集一定時間段的平均值，如平均值不超過閾值，則不認為是故障，不觸發自愈操作
7 、智能運維不是萬能的
智能運維并不是萬能的，智能運維的落地成功性在于精于業務、切合實際，關鍵點如下：
精于業務，了解業務的規律，才好選擇好的算法模型；
有了智能運維不代表就不需要運維人員了，因為畢竟算法是人寫的，機器學習還是需要有“運維老司機”進行調教的；
若想做好準確的預測，需要有足夠、精細的歷史數據為樣本；
需要將算法運用于貼合實際的某一個具體業務場景中，避免離譜夸大的設想，如“預測小米什么時候上市，沒準說著說著就上市了”，其實前幾天就已經上市了；
智能運維的前提最好是先實現自動化，否則即使檢測出故障和根因也無法自動修復；
一定要貼合實際情況，一步一步來，切勿期盼一口吃個胖子。
8、感慨下
業務智能運維，是運維發展的大勢所趨，無所畏懼，世間萬物皆連接，有了人工智能這一利器，加之我們對于業務的深層理解，以及運維領域的豐富經驗，相信中國移動智能運維體系的建成和落地，指日可待！！
注：文中少部分內容的思路和靈感參考于百度、清華大學、Linkedin、Yahoo等公司運維領域專家的大作，謝謝。
