雙十一阿里巴巴電商業務的高效資源運營之道
講師 | 楊儀
編輯 | 黃曉軒
講師簡介
楊儀
2010年入職阿里從事監控系統運維研發
2012年調入運維團隊，負責淘系核心交易系統運維
2016年負責系統軟體事業部資源運營團隊，負責阿里線上業務的資源運營。
負責過多年雙11交易運維保障，在自動化運維、DevOps、資源運營方面有一定的實踐經驗。
前言
大家好，我是楊儀，今天我給大家帶來一些關於資源運營方向的分享。我們今天討論的主要內容有四部分：
-
資源運營的演變
-
規模化運維平臺
-
降低資源成本
-
智慧化運營
資源運營的演變
首先我想分享一下整個阿里在 Devops 的演進歷程。
Devops 的概念這幾年是很火，阿里的業務運維也是經歷了這樣一個階段。
我剛進阿里的時候大部分運維相關操作，運維人員都是通過登機器、敲鍵盤去做的。逐步我們會有一些工具去操作、執行重複性的工作。
隨著業務規模不斷增大，團隊發現不可能無限數量地招運維人員去做重複的事情，所以引入 Devops。
經過這兩三年的發展，阿里線上運維基本上達到了初步自動化的狀態，同時我們正在向智慧化的方向摸索。
整體看下來我認為阿里在運維領域，容器化是 Devops 轉型過程中最重要的里程碑阿里現在線上業務中大規模使用 docker 容器。
接下來我想講一下阿里這十幾年來線上業務的升級。
未來運維的方向是 Opsless。
傳統運維能做的事情一定越來越少，最終有可能會做到 NoOps 的狀態。
近三年來運維人員規模沒有增長，甚至有些是下降的。
整體來看一開始是做面向單物件運維，配置檔案、包等這個時代已經過去了。
接下來是面向容器運維，當下演進的狀態，運維粒度擴大到image。第三個是面向Pod運維，業界流行，服務相關容器打包到Pod，進一步擴大運維粒度。第四是面向Box運維，阿里規模大，業態豐富，所以後面有可能到達第四個階段。
運維做久了以後他的上升空間，比方說整天都在做些運維的事情，那未來發展的方向是什麼呢？
在阿里運維他是有兩個方向要突破：
第一方向是迴歸到業務，和業務去做深度融合，比如專注去做智慧化監控、智慧化故障定位等。第二方向是下沉到排程領域，下沉到核心這塊。
我現在的團隊相當於做的是下沉這塊。所謂的資源運營就是指我們想要做超大體量的資料中心的資源管理策劃，做這些最終是為了降低整個阿里生態體系的資源執行成本。
想做到這些我們有很多挑戰：
-
建設統一排程的能力。阿里有很多業務，比如說淘寶、天貓、聚划算等等，各種各樣的電商業務，我們對這些業務怎麼去做資源的分配，這就需要我們有同步的調動器。
-
資源供需模式，需要的是集中式、扁平化的資源供需。把整個的線上資源排程能力作為中颱輸出。
-
提升資源利用率。大家知道線上業務要考慮容災、異地部署的需求，有的資料中心，叢集的利用率都不會很高，但阿里的資源利用率都在10%，整體來看提升空間非常非常大。
前面提到是資源運營本身的挑戰，我們從運維團隊轉型做資源運維，面臨更多的挑戰是圍繞著效率、成本、穩定性去解決雙11資源使用問題。
-
傳統運維運營向自動化運營的轉型。每到雙11大促，所有的業務都來和你說要加機器，以前都是人肉評估，人肉去運營的模式。我希望把這種運營模式轉化成系統運營。
-
資源需求的集中爆發。在雙11場景下，資源需求是集中爆發的，我們會有數十個BU，因為“雙11”這麼大的活動在阿里內部是整體協同的大作戰，包括優酷、菜鳥、天貓都會參與到“雙11”裡面來，那這裡面的需求量，很多很多系統都會來問我們要資源。
-
業務和成本之間尋求平衡。為了支援雙11，怎麼能夠用最低的成本去滿足最多的業務需求。
-
運維平臺要有很高的可靠性。
規模化運維平臺
基於前面的那些挑戰，我們最核心的關鍵是要打造一個規模化的運維平臺。阿里有兩萬多個工程師，每個工程師負責一個系統的話就有兩萬多個系統。
我們通過規模化運維平臺來提升資源運營的效率。
-
資源排程系統。提到了Sigma排程器，一站式資源交付。他可以很簡單的點幾下按紐，就可以把需要的資源交付給他。
-
資源管理的過程中引入了預算和額度管理機制。年初的時候希望每個團隊都向資源運維團隊提供未來一年資源需求的規劃。我們基於這個規劃會統一的看阿里巴巴集團未來資源的需求，然後會制定相應的資源交付計劃。
-
彈性伸縮。解決海量應用的容量備容效率問題。
-
解決規模化執行問題。
比如說雙11的時候要擴容幾十萬個容器上去，這對我們規模化執行的效率要求就很高。還有點現在都用的是容器，容器就會涉及到容器級別的偏袒，一臺物理機要怎麼樣部署，要有哪些組合才能讓這臺物理機上的資源運用好。
這是規模化運維平臺整體的架構。規模化運維的目標是做批量大規模的，不會去對單個應用做傳統的運維支撐，所以規模化運維是用很少的運維人員投入解決萬級別的系統交付。
首先在資源運營這塊有預算額度和整個的管理系統，比方說業務他要提交他的預算，整個系統會根據他的預算決定在哪個時間點交付多少資源。
第二是容量規劃，根據業務平時的表現可能會去推算未來阿里巴巴在明年的業務增長。
第三是彈性伸縮，我們會對所有的線上系統做實時的分析，在平時的時候通過彈性來做自動的容量管理。其實還有一系列的架構在裡面，比方說決策中心。
整個規模化的操作都會在決策中心做資料處理，比方說執行大規模的銷燬容器的動作，那可能就會由決策中心預判。上面是資源運營的體系，最下面是排程器。基於上面這套對最底層的容器去做一整套的管理。
這是額度生態。在阿里巴巴內部所有的系統使用資源都會有上限，就是在某一個時期你能用的最大資源數量。這個數量我們是把他細化，你能用多少核的CPU，能用多大的磁碟空間，基於這套額度系統會整個形成系統化的閉環。
降低資源成本
其實我們做的這些系統歸根到底是為了解決資源成本的壓力。阿里在2014年做下一年的財政預算的時候就預見到阿里巴巴未來在基礎設施的投入是非常非常難，第一年做預算的時候發現下一年要採購的機器數翻倍，這對於整個的投入是非常非常難。
這塊主要挑戰來自兩塊，一是像“雙11”的場景，很多人買買買，我們要提供幾十萬的峰值交易能力。
還有一塊是離線任務計算，也是有非常大的資源需求。像剛才提到“雙11”是很麻煩的事情，在“雙11”之前可能買了很多機器，“雙11”用完之後大量機器就閒置，那閒置成本對於阿里來說也非常非常高昂。
基於這些我們就想說怎麼樣才能用最少的成本去支撐“雙11”。首先想到用阿里雲，比方說去年30萬筆交易，我們有很大一部分都用的阿里雲的資源，因為阿里雲有這麼大的體量。
這裡面的技術難點主要是阿里集團要和阿里雲體系打通，怎麼樣才能快速的把電商業務部署到雲上去，基本上只用十幾二十天撐過“雙11”就可以，這樣成本會大幅度下降。
第二我們想到怎麼把手頭機器用好。線上服務，他的CPU利用率是跑的比較低的，剛才說到只有10%，但離線計算CPU用的比較高，就想這兩種服務能不能夠同時去跑。比方說把離線、實時計算、線上同時跑就可以達到很高的CPU使用率。
阿里大概從2015年開始就做這塊的嘗試，把不同的業務做混合部署。在阿里我們基本上是這麼做的，線上業務都是物理機，那離線直接在物理機上，像在日常情況下可以用線上的伺服器去滿足離線資源。這個技術給阿里帶來了極大的成本節省，現在CPU利用率已經能夠跑到很高的水位了，包括平時線上叢集上只有離線任務在跑，並且離線任務對線上的影響可以控制在10%以內。
智慧化運營
混部技術，平時離線可能佔用大部分的資源，那需要的時候可以快速把離線任務降下去，使線上跑起來。
線上排程器與離線排程器的協同，比方說線上業務突然有流量高峰的時候，我們可能就會把離線的第一優先順序任務除掉。
因為線上任務的優先順序相對來說是更高的，比如說使用者下單，要是超時可能就會產生投訴。另外在資源隔離這塊，怎麼樣讓線上業務他的資源有保障，因為離線任務的特點跑起來的話CPU會跑的很高，記憶體也會用的很快。
最後一個技術是在虛擬化做的嘗試。
應用畫像技術，這也是核心本身就有的，可能現在很多廠商還沒有大規模的用，但阿里已經大規模的用這套技術了，就是Cpushare。
傳統的容器化，如果說一個容器生成了4核的CPU，8G記憶體，60G的磁碟，那他的資源就是固定的，容器把資源預留住了，這些資源只能他用。這樣就會造成一些應用平時的業務量沒有那麼大，但依然佔容器，就會導致整體利用率不高。
那基於CPU下的這種模式具體說來我們把CPU拆成很多細碎的時間片，這個時間片比方說有個業務判斷出他對CPU的消耗量很低，那可能只分配0.1個核給他。就會出現比方說像右邊那種場景。
某個業務他可能部署的時候需要3.2個核，CPU核數用小數點來衡量，不會像現在這樣全部是整數。
還有個優點我們可以給容器設定他使用資源的上限，會保證最小能夠用多少資源，同時當你的系統提高時可以給更多的CPU資源，這樣靈活性就會很高。
我可以做到同一臺物理機上部署了兩個應用，可能都是同樣的規格，但有一個應用對資源的消耗很高的情況下，就可以把另外一個虛擬機器分配的資源給拿過來用，這對業務的判斷、識別要求非常非常高。
現在在 Cpushare 會主要做的是對應用畫像。你這個系統或者業務的資源是不是能夠被別人搶佔的，可能你是高中低三種優先順序，可能高優先順序的系統就可以搶佔低優先順序系統的資源。前面提到的混部、CPU的技術，都是為了“雙11”的時候阿里巴巴能夠儘可能少的採購機器。
我的分享就到這裡，謝謝大家。
問答環節
提問1：我問一下預算那塊，你們面對很多的部門提交上來，還是年度的，但這個做不準，因為經常會變所以怎麼樣應對呢？你們這個預算是整個集團的財務還是運維這塊的審批？
答：首先我們有個優勢，系統軟體部門的任務是把所有阿里的資源彙總起來，就是說要先向他收錢的。我們會制定出每臺伺服器每天使用的價格是多少。
在預算變的情況下，首先我們的池子足夠大，如果業務方的需求變了，那要看他到底是增加還是減少，如果是增加的情況下可能會讓他在BU內，BU的老闆必須同意用這筆資源，因為他用這筆資源我們是要向他收錢的。
對我們大團隊來說，我們考核KPI是怎麼向業務方收更多的錢，讓我們的盈利越來越多，當然收更多的錢並不是說去提高單位機器的單價，但一定是通過各種資源複用的手段。
預算現在是走比較嚴格的審批機制，大部分需求只要在BU層面，有些涉及比較大的採購，那可能又要到管理層去審批，一般我們不會讓這種情況發生，因為大多數情況下我們都有辦法擠出這份資源，只要BU同意，我們是可以有資源交付給他使用。
提問2：楊老師我問一個問題，關於您提到阿里雲內部資源有一個相當於調配的過程，我想了解一下阿里雲的資源是不是在整個阿里體系內管理的一部分，如果說在“雙11”或者業務使用高峰期，你們是怎麼樣進行阿里雲使用和內部資源的使用？
答：首先阿里電商去用阿里雲的資源一定不會說從公有云使用者那邊去搶資源，我們一定是用阿里雲的存量，因為阿里雲平時都要準備，我們不會說和公有云上的使用者去搶，但你可以認為所有的環境都是一樣的。
提問3：我想問一下你前面提到了節省資源，以前做運維比如說一個伺服器會控制一些資源，那聽說你們好像浪費率在10%以下，這時候如果一旦出現系統資源緊張，這是怎麼樣的？
答：首先糾正一下，前面10%這是不到10%的利用率，你的問題是說出現突發需求怎麼辦。
我想說的是以前運維模式是說每個BU的運維負責人手裡都留了一份buffer，以備不時之需，那在我們這裡也會留buffer，但這只是一個數字。
我們做了一個事情，把全集團所有的buffer全集中起來了，每個BU手裡有的buffer相當於一張支票，因為所有的buffer聚集在一起他的體量是足夠龐大的。在“雙11”這種場景稍微有點特殊，很多人都拿著支票來說取現兌現，就像銀行被擠兌一樣，這種情況下我們的壓力是會大一點。
提問4：楊老師您好，像資源池這塊負責運維的時候，負責的界線你們是怎麼確定的？就比如說像作業系統還有中介軟體、資料庫的維護是怎麼樣的？
答：其實我發現今天演講把這部分漏掉了，在阿里是這樣的。我們做容器化以後會發現運維的生活質量大幅提升。
我們以前傳統的運維，在做容器化之前要應對各種各樣的需求，比如說今天要改個case，明天要調個什麼東西，容器化以後發現他全部可以做了。
那阿里現在這幾萬個應用絕大部分日常的運維工作全部交給了開發，我們想說的是運維的減賦不一定是通過DevOps來實現。阿里有兩萬多名工程師，那每人做一點可能運維團隊就非常輕鬆。
像你剛才提到的，比方說研發自己的系統，現在我們還是有些基礎的組建，比如說像中介軟體、分散式儲存，這部分還是有獨立的團隊在支援，這塊的運維量遠沒有應用運維那麼大。阿里現在相當於在用這套模式做DevOps落地。
我們的這個是從整體來看，運維轉型以後做的更多是研發工作，比方說開發彈性伸縮系統。不知道大家之前對阿里雲的故障有沒有印象，運維團隊開發的程式碼推到線上，在測試的過程中觸發了一個BUG。
點選 閱讀原文 ，立即訂票