本期嘉賓：百度運維技術經理 曲顯平
演講會議：部分內容選自 1024學院旗下品牌iTechClub主辦·華南區第六屆互聯網技術精英高峰論壇
整理編輯：小猿
運維一直是個繁重的活，并且隨著公司規模的增大，運維壓力直線提升。
有一張大餅圖揭示了運維的工作時間都消耗在哪里：
可以看見，47%的時間消耗在兩項工作中：
1.執行實際的部署工作。
2.修復與部署工作有關的問題。
這一方面是日益增長的龐大業務線問題，一方面是研發和運維日益嚴重的隔閡問題，剩下的就是手動運維到自動運維的轉化問題。
就業務復雜度而言，單以百度來說，就包括七大業務線：搜索，廣告，地圖，金融，云，無人車，AI，且每條業務線都很重要，相關的運維平臺需要大量的單獨對接和開發。
而研發和運維的低效率溝通就更古怪了。長期以來，雙方所屬部門不同，日常工作的側重點不同，使用的經費也不同，導致一堵無形的壁壘出現在中間。但最終大家發現，不管基于何種目的，只要配合不默契最后的結果都一樣：項目失敗。
最后在自動化運維的問題上，大家有一個普遍的錯覺：我們就是自動化運維。但實際上根據調查，在運維情境中，61%的企業使用腳本完成的工作占比低于10%。
而手動輸入指令這件事有多要命呢？請看下方的面條圖：
僅僅手動輸入五條命令，成功率就跌到了86%，手動輸入200條命令，成功率約等于0%。
所以現代運維的問題主要可以歸結為一句話：活兒多嘴笨還手殘。
在這種情況下最先出現的是DevOps， 很多人提起DevOps喜歡立刻吐出一堆工具鏈，比如puppet，Docker，Redmine，Jenkins，Zabbix等等，但實際上DevOps是一個方法論，自動化運維只是其中的一部分。
本質上，DevOps是為了解決掉通往敏捷開發路上的一切障礙，打破相關各部門的溝通壁壘，全自動化運維部署。
簡單點說，主要是打破研發和運維的溝通壁壘：
說全一點，是解決開發、運維、QA三方的溝通問題：
那么DevOps有用嗎？有用，有大用，據一份第三方統計機構調查3200位從業人員以后的信息顯示：
組建了DevOps團隊以后，代碼部署頻率提高了46倍，但變更失敗率卻降到了之前的五分之一。
但這種事你始終要多留一個心眼來看，DevOps是一個方法論，而不是一套確實的開源工具，更不是哈利波特的魔杖，具體執行起來的效果肯定會有優劣之分。
而且但凡可以歸結為一個方法論的東西，就存在相當的模糊性，從許多從業者甚至說不準DevOps的概念這點就可見一斑。
不然百度也不會再加上一套SRE體系與其互補。
SRE是谷歌率先提出來的概念，全稱是Site Reliability Engineer (網站可靠性工程師)，要求更高更直接，就是要求你既會開發，又懂運維。
得咧您吶，就您自己干吧，只要不是精神分裂，應該不存在什么溝通問題。
SRE一般都是從研發工程師轉行的，唯一目的就是保證網站不宕機。但這種復合型人才的招聘難度也很大，涉及到職位賦能時大家更懵，如果使用SRE體系，中小企業基本就可以說拜拜了，反正你也招不到人。
在這種情況下，百度開始了更高階的運維方案實踐之路：AIOps。
AIOps，也就是基于算法的IT運維（Algorithmic IT Operations），是由Gartner定義的新類別，源自業界之前所說的ITOA（IT Operations and Analytics）。
目前百度團隊對AIOps的應用主要有四個方面：故障管理，變更管理，容量管理，服務咨詢。
核心包括三個方面：運維知識庫，運維開發框架，運維策略算法平臺。
在構建AIOps之前，百度將問題場景歸納在四個象限之中：
類似全網宕機等重大故障，雖然問題復雜，但屬于低頻問題；像監控管理、部署變更類工作，雖然問題并不復雜，但發生頻率很高。
站在運維的角度上，優先考慮解決高頻、簡單的應用場景，因為這種問題雖然往往簡單，危害低，但是卻消耗了大量的人力。（老板想的正好相反，并叫你到辦公室來一趟）
基于對問題場景的理解，百度首先規劃了龐大的運維數據網絡，即三個核心之一的運維知識庫。
從圖中可以看出，運維數據主要分三大類。
第一類是元數據，元數據可以理解為針對任何一個個體單位的數據，這個個體可以是一個產品，一個人，一個APP，一個網絡，等等。
第二類數據是狀態數據，這些數據是傳統運維最關注的部分，涉及硬盤，內存，cpu的使用情況等。
第三類數據叫做事件數據，是最難歸納的數據，包括一些告警、緊急方案等等。它相當于基于運維的理解，歸納出的邏輯數據。該數據的準確與否，直接影響整個系統的行為。
就像我們曾經在過去的文章中反復提到的一樣，沒有數據的AI開發都是扯淡，百度整理這套數據總共耗費了四年有余。
準確的歸納出運維的指標數據是一件相當困難的事，數據必須完整又足夠描繪出整套運維框架，這是AI版的“0和1”。
建筑在運維知識庫（運維數據）之上的，才是完整的運維開發框架：
在這張令人眼花繚亂的架構圖中，有兩項工作最困難，卻又是我們最熟悉的。
1.模塊的抽象和封裝
在所謂的OPAL（operation abstraction layer）部分，所需要的還是大量的完整的封裝工作，可以說自打有模塊化開發的概念，良好的抽象封裝在架構設計上就一直是個繞不開的彎。
復雜的交流，復雜的接口，本質上都是抽象和封裝的不完善。
比如你說你想吃胡同東頭的山東大蒜拌意大利面，同伴說想吃西頭的牛肉漢堡沾東北大醬，然后你們開始為了吃法而爭論不休。
其實正確的說法是：“我餓了，吃飯吧。”
2.大型測試環境的構建
而在Develop Tool Chain部分，有一個Test，涉及大型測試環境的構建。
這點研發和運維的怨言倒是史無前例的達成了統一。很多公司糾結成本問題，舍不得買服務器構建大型的機房級別的測試環境。
實際上很多線上問題的根源就在這，測試環境和線上環境的差距過大。
這一點 百度做到了。
看的出來，不管我們把AI這個詞講的多么高端，很多基礎問題仍然圍繞在IT圈說了二十年的東西，數據、抽象、測試環境，這是一條沒有捷徑的路。
很多人聽到AI樂夠嗆，以為冒出來個黑科技，把坑都繞過去了。實際上這個“黑科技”是幫你在傳統大坑后面，挖好了下一個坑，只不過最后到達的地方，天空也更加蔚藍。
在漫長的基礎準備工作后，AIOps終于開花結果，以下是三個百度在AIOps方向上的實踐例子：
1.智能故障自愈
其核心還是運維知識庫，由于IDC故障的原因五花八門，歸納異常事件的種類完全是個技術活兒。但在這方面的工作越優秀，也意味著整個系統越智能，據說，谷歌已經可以達到任何一個IDC的故障自愈。
2.無人值守上線
早期可能還是需要人工檢驗規劃結果，目標是慢慢徹底的去人工化。
3.智能客服機器人
在服務企業內部的智能客服上面，百度在自然語言處理方面有天然的研究優勢，而且單獨對于運維場景來說，該系統的難度要降低很多。
畢竟運維同學應該不會閑著沒事去找智能客服聊騷。
如同AI技術的不斷發展一樣，AIOps的演化也在不斷地進行，從自動化到智能化，這是一個升級蛻變的過程。
但運維同學也不要過于高興，誰說以后就是“喝著咖啡做運維”了？興許以后就沒有運維了呢？
