《實戰：阿里巴巴 DevOps 轉型后的運維平臺建設》要點：
本文介紹了實戰：阿里巴巴 DevOps 轉型后的運維平臺建設，希望對您有用。如果有疑問，可以聯系我們。

本文轉載自公眾號「DevOps 時代」,高效運維社區致力于陪伴您的職業生涯,與您一起愉快的成長.

作者簡介：

陳喻(亞松)
阿里巴巴 高級技術專家
2014年入職阿里負責 Aone(持續集成,持續交付平臺)研發團隊,2015年調入運維團隊,負責交易運維、無線運維2個團隊,帶領團隊保障日常運維及雙11大促運維.2016年負責中間件的 DevOps 平臺團隊,團隊主要業務方包括淘寶、天貓和聚劃算等.個人獲得2016年雙11卓越貢獻獎.

前言

本文根據 DevOpsDays 北京站演講記錄整理而成,重點是關于阿里巴巴DevOps 轉型之后,運維平臺如何建設的.

首先講一下轉型,以前的 PE 人員可以去做運維平臺,有一個很大的原因是轉型里非常重要的策略—“我是這個應用的 Owner.”

當時,我們 CTO 跟所有研發同學說：

從轉型開始的時候,所有的應用要自己去做運維,我是這個應用的 Owner.

運維有這一個策略以后,PE大量的日常工作就可以釋放出來,就有更多的時間去做思考,去做沉淀,去做編碼,去做我們以前不曾做的事情.

本文主要分為兩大塊內容：

第一,怎么去思考我們這個運維平臺,有一些結合運維自身的理解,結合業務場景的分析,包括業界的方法論的一些思考,結合我們自身的問題,得出來的一些最佳的實踐.

第二,介紹一下我們整體運維平臺主要的功能.希望大家聽我第一塊的時候就知道你怎么建設你的運維平臺,我后面做的,場景問題你沒有必要按照我們這樣去設計.

運維的三個階段

• 第一階段,黑屏,三角形我的意思是代表整個運維給用戶的一些體感或者給研發的體感,人工運維,其實很多企業里面有可能還是這樣.
• 第二階段,白屏,我們自助運維,以前把腳本做成工具去弄,有什么特征,人push機器去干活,自助運維.
• 第三階段,用戶對運維體感很少,但是運維這個領域是不變的.最重要的是人機交互變少了,無屏雖說是不可能的,非常極端,但是是一個趨勢,少量的人機交互,它有自決策、自驅動.

自動化運維基礎

我們做自動化運維,我認為有四大基礎.做這個事情不做,它一直會讓你痛.

第一,運維標準與規范

我們的標準有什么好處,讓研發 follow 這個標準,標準會在工具里固化.

第二,泛監控,運行時,靜態,數據化,可視化

泛監控,不是說傳統的監控,是把線上想知道的一切都數據化,最終數據不是給人看的,是給機器去消費的,數據是我們的生產資料,不是可視化,那不是我們的目標.

第三,CMDB

今天說得太多了,非常重要,我想回答兩個問題：

第一,CMDB 應該放什么,一般放服務器相關的、網絡相關的、應用相關的這三個維度的相關信息.

第二,經常有人會說 CMDB 不準,數據不準是因為你沒有把數據生產和數據的消費形成閉環,如果你形成了閉環,數據不準,只是你不敢用,很多人就是這樣的,因為你數據不準,所以我不敢用.這不是理由,你用,出了問題,是誰就搞誰,CMDB 就這么搞,其實方法很土,你不用這個數據永遠不準.

第四,高效的CI/CD/CD

最后一個,我們一定要具備快速的交付能力,主要體現這兩個方面,第一個新開發的能力能不能快速上線,第二是想擴容一臺機器能不能快速擴出來.這兩個能力我抽象出來是三個東西.

• 持續集成(CI),很多人說持續集成工具不好用,效率低,其實持續集成的本質里面是要自動化測試.如果研發部不具備自動化測試的這個 sense,你持續集成怎么做都是失敗的.

  持續集成里最重要的一點就是要推行我們的測試單測、集成測試還有系統測試,單測是保證自己沒問題,集成測試是保證跟上游下游沒問題,系統測試是保證整個系統沒問題.

• 持續交付(CD),現在有很多人說持續交付本質是一個 Pipeline,CI的目標是什么,快速正確去打一個包出來,CD的目標是什么?我能夠快速把一個包在不同的環境驗證它是ok的可以放到線上去,這就是持續交付要干的事.

  持續交付里面很關鍵的一點,我們要去解決掉,就是它的環境一致性、配置一致性.環境一致性可以用Docker去解決,Docker 其實本身就是一種標準化的東西.

  所以說第一條用 Docker,肯定是標準化的,另外一個問題,配置是不是一致性,是不是動靜分離.

• 持續部署(CD),是一種能力,這種能力非常重要,把一個包快速部署在你想要的地方.

PS：持續部署的幾個痛點.

第一個,對你包的文件的分發,大家可以看看我們阿里自己做的,是一個同學做的一個叫蜻蜓的產品,他是做了 SP2P,在 P2P 的基礎上加了一個 Super,

第二個,我的應用啟動,這個說是挑戰,其實是我以前做這個產品對別人的挑戰,很多應用啟動的時候要兩三分鐘,這是很有問題的.

第三個,我們部署起來以后這個業務是不是正確的,大家一定要做一個 HealthCheck,不是我們運維來做,是PE來做,一定要把這個要求說出來,執行 HealthCheck 這個腳本.

運維系統的重要特性

我們的中間件研發關注穩定性,其二是效率,其三是易擴展,什么是中間件,大家應該都知道,運維研發里面我說的這六個東西,其實每一個都是非常重要的,如果你沒做好,真的可以引起災難性的問題,但是還是強調幾個我感觸比較深的.

• 第一,高可用

  我們在做同城容災演練的時候,我把網一切,結果發現運維系統掛了,救命的東西沒有了,怎么搞,當然這種情況我們沒有發生過.所以說我們的運維系統一定要是高可用,不一定是高并發.

• 第二,冪等性

  冪等性是分布式系統設計中十分重要的概念,這個也非常重要.

• 第三,可回滾

  這個是我們做運維最基本的一個 sense,你做的任何操作是不是可控的,大家最近知道很多故障,包括亞馬遜的,其實都是一個小的誤操作.我們如果真正做可回滾,其實事情沒有這么復雜.

• 第四,高效率

  如果你的企業發展非常快速,你的規模性效應已經來了,你的運維系統一定要具備很高效率,主要體現在什么地方,其實運維很多地方不一定要求效率非常高,但是有幾個地方要求非常高,快速擴容、快速部署這個效率我們要追求極致.

研發定義運維,配置驅動變更

其實我們有時候做決策最困難的是信息不對稱,如果我去炒股,旁邊坐個專家跟我炒,如果我知道內幕消息,他死活炒不贏我.

因為我知道內幕,就知道明天要收購,這就是信息不對稱,我們今天的企業,信息不對稱,部門與部門之間,子公司之間,包括系統與系統之間,信息大部分不對稱,這么多不對稱,你又不知道你的現狀,你又不知道你的目標.

這個是2015年11月4號,那個時候雙十一剛剛搞完,我去思考,就是我想做一種能力,這個倒下的讓它舉起來,這個能力把它搞起來,就是不倒翁原理,我想到這樣的架構.

從最下面講,這是我們基礎設施,提供三種能力,集散、存儲、網絡、無論你是怎么樣搞,就是提供這三種能力.從右下角的位置上,我先畫的是一個泛監控,它會知道系統、應用等等,我把它旁邊標了一個字,現狀,我要通過這個現狀把線上的系統全部數據化,然后我放到決策中心.

左上角有 CMDB,我們現在很多變更系統,很多強調流程,說實在的,其實我本人是做研發出身的,我非常抵觸流程,流程不是一個效率工具,它是阻礙效率的.

我指的流程就是說,我們故障搞完以后就是一堆的流程,流程非常阻礙效率,是質量控制的一個工具.流程不是不要,是把流程做到系統里面去,讓系統去幫人做決策,而不是人在那里點,天天打個電話讓你去點,然后我們還要做到事后審計.

CMDB 定義了我剛才說的目標,我的現狀通過監控拿到了,目標也知道了,這個時候你覺得這個事情很復雜嗎,我認為這看你怎么去做,如果你想做成人工還是做成自動還是做成智能,都取決于這個地方.

所以我們智能里一定要具有數據的,你知不知道你的目標是什么,所以智能對大家來說就是我說的決策中心里該干的事情,把目標的數據拿到了,就能快速進行決策.

說個最簡單的例子,通過智能分析出目標狀態是使這個應用有100個VM,但是現在狀態只有80個,一看這兩個不一樣,要擴容20臺,如果系統做得更智能一點,通過圖上左邊的事件中心提示我20臺負載較輕的放在哪,就可以調度過去,然后去做執行變更.

我基于這些東西得出來兩個結論,“研發定義運維”,“配置驅動變更”.

為什么是研發定義運維?

我在2015年11月時說研發定義運維,我取了個名字,DDO,為什么是研發定義運維,研發最貼近業務,最應該清楚這個業務應該具備什么樣的能力,所以說只有研發才能夠知道這個業務KPS應該是多少,我后面還會講去做容量預測等等這些事情,但是一般來說,它的目標狀態是研發會去說的,這是我這個服務上來提供多少的服務能力.

為什么是配置驅動變更?

配置就把目標改變一下,你隨便跟我說一個運維場景,我可以給你在這個圖里面 run 起來,我們配置只需要改你的目標狀態,我把你的狀態10VM 變成15個VM.這就是我說的研發定義運維,配置驅動變更,前因后果的思考就是這樣的.

2.3 運維工具與方法論

精益發現價值

我看到的最大的感觸是價值,價值來源于用戶的需求,我們價值很多時候是來源于自己的YY,我們的價值來源于用戶.

精益對我最大的感觸就是我們要發現價值.我發現了價值,我們做的目標,很多人在定 KPI 的時候跟我講我做了 A、B、C、D 功能,我說三個字,然后呢?

為什么要引入 Docker、kubernetes、Jenkins?你知道現在的痛點是什么嗎?如果你不能就不要做這些東西,我們往往看別人是看得最清楚的,看自己看得不清楚.

今天也有人問我,DevOps 團隊是該拆還是該合,我說你面對什么樣的問題你知不知道,你思考過沒有,你的問題優先級是什么,如果只給你解決一個問題是哪個,也許并不是 DevOps 團隊拆不拆的問題.

精益思想,什么東西是有價值的,能夠對用戶帶來物質上的或者身體上的愉悅的東西就是有價值的.

敏捷交付價值

敏捷也是對我影響很多的,很多人談敏捷,我團隊里也搞敏捷,敏捷這種運動這種方法是非常靠譜的,它是一系列的方法論.但是在你引入的時候,千萬要注意,別人行的東西你不一定行,你需要的東西并不一定是敏捷.

敏捷里面,我們快速去交付價值,在引入敏捷的時候,一定要看,因團隊而異,跟團隊的成熟度不一樣,它的方法也不一樣,如果一個非常成熟的團隊,任何跟他講都是影響他效率的.

如果一個不成熟的團隊,你就要告訴他,一開始啟動會議,然后站會,嚴格按著這個動作來.武功最高境界有兩種,一共是天下武功唯快不破,還有一種是無招勝有招,別人做這個事情蹲馬步了幾十年,你上來就說無招勝有招.敏捷里我們要形成一個環,持續反饋.

OODA環

OODA 環,一定要形成環.我看了這些東西,我所看到的東西是什么,就是形成閉環,讓價值快速流動.

應用運維平臺ATOM

這是架構圖,因為你的企業可能不一樣,我們這個系統每一個小塊可能就是一個系統.

我們的基礎設施是一層,二層是運維中臺,最上面一塊是要做的 PaaS 平臺,這個平臺我分了幾步.

• 第一塊,預算、容量、資源、彈性
  這些東西加在一起是干什么,其實就是要讓資源快速流動起來,流向正確的方向來產 ? 生價值,你的資源如果常年不增不減,這是有問題的.這個在我的 PaaS 平臺是非常重要的一塊,目的就是讓你的資源快速流動起來.
• 第二塊,應用管理
  我們要做日常的操作,這個東西全部是讓研發去做,就不去做了.這是規模化,阿里的場景很大,要快速對一個單元建站、擴容、縮容.
• 第三塊,數據化運營
  一定要講數據,數據一定不是可視化出來一些報表,一定要給結論,告訴用戶你這個數據完了以后應該是什么.規則中心是什么,就是我們所有運維同學日常的運維經驗的沉淀,你在線上希望是什么樣子的,應該把你的經驗全部固化到規則中心去.

批量騰挪工具

這個工具不定所有人都需要,可以解決什么問題,機房的搬遷,湊框遷移.

我們還做了單機閉環,這是騰挪工具的關鍵,如果企業發生了一定規模,這個東西一定是會需要的.

彈性伸縮工具

然后是彈性伸縮,就是我們的決策中心,解決什么痛點,讓你的資源流動起來的決策,它決定你的資源怎么去流,往哪個地方流,這個東西非常關鍵.

最后它也是說運維領域里面技術含量最深的一個地方,要搞機器學習、深度學習、強化學習等等,算法一堆的東西,我們在這里去弄.

彈性平臺主要解決什么問題,這是我們的架構,這個平臺不一定很多企業都需要,但是我想講個應用場景就是在雙十一的時候是怎么用的.

我們建一個站點起來只有5000的交易能力,可以通過10分鐘時間讓它具有30000萬的能力,快速決策,快速調動起來.彈性里面就是一個 OODA 環,拿他的數據,跟應用極限做比較,得出來一個策略中心.

彈性一般有水平伸縮、垂直伸縮,對線上去做管理,當然我們有額度,這是比較精細化的管理,今天可能沒那么多時間分享.彈性有觀察者模式還有自動化執行,每次彈性完以后有一個控制臺,因為雙十一做全年壓測的時候一般情況下不看這個東西.

我剛才講的很多東西,沒有說怎么做成本,怎么做效率,等等這些東西,但是我們做了這些事情,的確是為公司省了錢,帶來一些收益.

我們的展望,PE 轉型以后,我們是希望讓研發來使用我們的運維,降低他運維的復雜度,降低運維的門檻,我們是通過系統化的方式來做,研發只需要把他的目標寫出來,讓運維這個東西像山一樣沉下去,感知不到.

然后是資源的閉環.規模化,現在PE做兩大塊,第一是規模化運維,然后是單應有運維,很多人理解把線上系統發布到線上去,擴容幾臺,這就是單應用運維.其實我們應用的藍海是規模化運維,這會涉及到方方面面的事情.

小結

本文講的四條,希望大家真的能夠理解：

首先：為什么 CMDB 很重要,為什么監控很重要,為什么標準很重要；

第二：研發定義運維,配置驅動變更,這是我們做這個系統的一個最基礎的理念；

第三：基于目標管理,你產品有沒有理念,如果沒有,我認為這只是功能的堆砌；

第四：形成閉環,讓資源流動起來,讓你的 CMDB 里的數據流動起來,讓你的資源流動起來.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2214.html