作者：陳喻（亞松）
來源：公眾號「DevOps 時代」，本文根據 DevOpsDays 北京站演講記錄整理而成。

阿里巴巴 DevOps 轉型之後，運維平台是如何建設的？阿里巴巴高級技術專家陳喻結合自身對運維的理解，業務場景的分析和業界方法論的一些思考，得出來一些最佳實踐分享給大家。

「我是這個應用的 Owner」是阿里巴巴 DevOps 轉型的重要策略，運維有了這個策略以後，PE 大量的日常工作就可以釋放出來，會有更多的時間去思考沉澱，去做編碼，去做以前不曾做的事情。

運維的三個階段

運維的三個階段分別如下：

• 黑屏，人工運維，三角形是代表整個運維給用戶的一些體感或者給研發的體感，目前很多企業可能還是這樣。
• 白屏，自動化運維，以前把腳本做成工具去弄，有什麼特徵，人 push 機器去幹活，自助運維。
• 無屏，智能化運維，用戶對運維體感很少，但是運維這個領域是不變的。最重要的是人機互動變少了，無屏雖說是不可能的，非常極端，但是個趨勢，少量的人機互動，它有自決策、自驅動。

自動化運維基礎

做自動化運維，我認為有四大基礎：

• 運維標準與規範。我們的標準有什麼好處，讓研發 follow 這個標準，標準會在工具里固化。
• 泛監控，運行時，靜態，數據化，可視化。泛監控，不是說傳統的監控，是把線上想知道的一切都數據化，最終數據不是給人看的，是給機器去消費的，數據是我們的生產資料，不是可視化，那不是我們的目標。
• CMDB。CMDB 應該放什麼，一般放伺服器相關的、網絡相關的、應用相關的這三個維度的相關信息。
• 經常有人會說 CMDB 不准，數據不準是因為沒有把數據生產和數據消費形成閉環，如果形成了閉環數據不准，那是因為你不用這個數據，所以不准。
• 高效的 CI/CD/CD。我們一定要具備快速的交付能力，主要體現在兩個方面：第一，新開發的能力能不能快速上線；第二，想擴容一台機器能不能快速擴出來。

上面兩個能力抽象出來，有如下三塊：

• 持續集成(CI)，很多人說持續集成工具不好用，效率低，其實持續集成的本質是要自動化測試。如果研發部不具備自動化測試的能力，持續集成怎麼做都是失敗的。
• 持續集成里最重要的一點就是要推行單元測試、集成測試還有系統測試。單測是保證自己沒問題，集成測試是保證跟上下游沒問題，系統測試是保證整個系統沒問題。
• 持續交付(CD)，有很多人說持續交付本質是一個 Pipeline，CI 的目標是什麼？快速正確打一個包出來。CD 的目標是什麼？能夠快速把一個包在不同的環境驗證它是 ok 的，可以放到線上去，這就是持續交付要乾的事。
• 持續交付里很關鍵的一點我們要解決，就是它的環境一致性、配置一致性。環境一致性可以用 Docker 解決，Docker 本身就是一種標準化的東西。
• 所以說第一條用 Docker，肯定是標準化的，另外一個問題，配置是不是一致，是不是動靜分離。
• 持續部署(CD)，是一種能力，這種能力非常重要，就是把一個包快速部署在你想要的地方。

持續部署有如下三個痛點：

• 對包的文件的分發，阿里有一個叫蜻蜓的產品，是做了 SP2P，在 P2P 的基礎上加了一個 Super。
• 應用啟動，很多應用啟動的時候要兩三分鐘，這是很有問題的。
• 部署起來以後這個業務是不是正確的，大家一定要做一個 HealthCheck，不是運維做，是 PE 做，一定要把這個要求說出來，執行 HealthCheck 這個腳本。

運維繫統的重要特性

中間件研發首先關注穩定性，其次是效率，然後是易擴展。運維研發裡面的六個重要特徵，每一個都非常重要，以下是我感觸比較深的幾個：

• 高可用，在做同城容災演練的時候，我把關一切，結果發現運維繫統掛了，救命的東西沒有了怎麼辦？所以說運維繫統一定要高可用，不一定是高並發。
• 冪等性，冪等性是分布式系統設計中十分重要的概念，也非常重要。
• 可回滾，這個是做運維最基本的一個 sense，你做的任何操作是不是可控的。如果真正做可回滾，事情沒有這麼複雜。
• 高效率，如果你的企業發展非常快速，你的規模性效應已經來了，你的運維繫統一定要具備很高效率，快速擴容、快速部署這個效率我們要追求極致。

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

2015 年 11 月 4 日設想的架構圖

從最下面看，是我們的基礎設施，提供三種能力，包括集散、存儲、網絡。

從右下角的位置看，畫的是一個泛監控，它會知道系統、應用等，在旁邊標了一個字，現狀，我要通過這個現狀把線上的系統全部數據化，然後放到決策中心。

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

比如故障搞完以後就是一堆的流程，非常阻礙效率，是質量控制的一個工具。流程不是不要，是把流程做到系統裡面去，讓系統幫人做決策，而不是人在那裡點。

CMDB 定義了我剛才說的目標，現狀通過監控拿到了，目標也知道了，這個時候還覺得這個事情很複雜嗎？

我認為這看你怎麼去做。想做成人工還是做成自動或者做成智能，都取決於這個地方。所以智能里一定要有數據。

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

基於這些東西得出來兩個結論，「研發定義運維」，「配置驅動變更」。

為什麼是研發定義運維？

研發定義運維（DDO），研發最貼近業務，最應該清楚這個業務應該具備什麼樣的能力，只有研發才知道這個業務 KPS 是多少。

為什麼是配置驅動變更?

配置就是把目標改變一下，你跟我說一個運維場景，我可以在這個圖裡面 run 起來，配置只需要改你的目標狀態，比如把你的狀態 10VM 變成 15 個 VM。

這就是「研發定義運維，配置驅動變更」前因後果的思考。

運維工具與方法論

精益發現價值

價值來源於用戶的需求，而不是自己的 YY，我們的價值來源於用戶。

精益對我最大的感觸就是要發現價值。精益思想，什麼東西是有價值的，能夠對用戶帶來物質上的或者身體上的愉悅的東西就是有價值的。

今天也有人問，DevOps 團隊是該拆還是該合，我想他應該首先弄清楚面對的是什麼樣的問題，問題的優先級是什麼？如果只解決一個問題，也許並不是 DevOps 團隊拆不拆的問題。

敏捷交付價值

敏捷也是對我影響很多的。很多人談敏捷，我們團隊里也搞敏捷，敏捷是要快速交付價值，它是一系列的方法論。

但是在引入的時候千萬注意，別人行的東西你不一定行，你需要的東西並不一定是敏捷，要因團隊而異，形成一個環，持續反饋。

OODA 環

OODA 環，就是形成閉環，讓價值快速流動。

應用運維平台 ATOM

應用運維平台的基礎設施是一層，二層是運維中台，最上面一塊是要做的 PaaS 平台，這個平台分為如下三步：

• 預算、容量、資源、彈性。這個是 PaaS 平台上非常重要的一塊，目的就是讓資源快速流動起來，流向正確的方向來產生價值。資源如果常年不增不減，是有問題的。
• 應用管理。這是日常要做的操作，規模化，要快速對一個單元建站、擴容、縮容。
• 數據化運營。一定要講數據，數據不是可視化出來一些報表，是要給結論，告訴用戶這個數據完了以後應該是什麼，規則中心是什麼，是所有運維同學日常的運維經驗沉澱。

批量騰挪工具

這個工具不是所有人都需要，可以解決機房的搬遷，湊框遷移。

單機閉環，這是騰挪工具的關鍵，如果企業有一定規模，這個是需要的。

彈性伸縮工具

彈性伸縮是我們的決策中心。它決定你的資源往哪個地方流，非常關鍵。

最後，這裡是運維領域技術含量最深的一個地方，要搞機器學習、深度學習、強化學習、算法等。

彈性伸縮架構，這個平台不一定很多企業都需要，這裡主要介紹在雙 11 的時候是怎麼用的。

建一個站點起來只有 5000 的交易能力，可以通過 10 分鐘時間讓它具有 30000 萬的能力，快速決策，快速調動起來。

彈性裡面是一個 OODA 環，拿它的數據和應用極限做比較，得出來一個策略中心。

彈性一般有水平伸縮、垂直伸縮，對線上做管理，當然我們有額度，這是比較精細化的管理。

彈性有觀察者模式還有自動化執行，每次彈性完以後有一個控制台，雙 11 做全年壓測的時候一般情況下不看這個。

實施效果

我們的展望，PE 轉型以後，希望讓研發來使用我們的運維，降低他運維的複雜度，降低運維的門檻。

我們是通過系統化的方式來做，研發只需要把他的目標寫出來，讓運維這個東西像山一樣沉下去，感知不到。

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

作者：陳喻（亞松）
簡介：阿里巴巴高級技術專家。2014 年入職阿里負責持續集成持續交付平台研發團隊，2015 年調入運維團隊，負責交易運維、無線運維 2 個團隊，帶領團隊保障日常運維及雙 11 大促運維。2016 年開始負責 Sigma 彈性&資源運營團隊，主要領域為集群彈性，應用彈性，資源運營，規模化運維，支撐雙 11，在 2016，2017 連續 2 年獲得雙 11 卓越貢獻獎。