一年節省近千萬 | 美團研發團隊資源成本優化實踐

導讀：美團到餐研發團隊對資源成本進行了一系列優化，目前整體技術資源成本每個月降低近32%，一年節省開支幾千萬，並且得到了多項專利，咱們一塊兒來看看，他們是怎麼作到的？

本文來源 | 美團技術團隊

做者 | 劉強，美團到店餐飲研發中心數據方向負責人，美團技術委員會數據技術通道委員，2017年入職美團點評，就任於到店餐飲研發中心，負責到餐數據倉庫、數據產品、數據系統的研發工做。以前曾任多家公司的數據方向負責人。

01背景

工程師主要面對的是技術挑戰，更關注技術層面的目標。研發團隊的管理者則會把實現項目成果和業務需求做爲核心目標。實際項目中，研發團隊所需資源（好比物理機器、內存、硬盤、網絡帶寬等）的成本，很容易被忽略，或者在很晚才考慮。

在通常狀況下，若是要知足更多的技術指標如併發量和複雜度等，或者知足峯值業務的壓力，最直接有效的方法就是投入更多的資源。然而，從全局來看，若是資源成本缺少優化，最終會出現以下圖所示的「邊際效用遞減」現象——技術能力的提高和資源的增幅並不匹配，甚至資源的膨脹速度會超過技術能力的提高，從而使技術項目自己的ROI大打折扣。

從筆者十餘年的工做經驗來看，資源成本優化宜早不宜遲。不少管理者在業務發展的較前期階段，可能並無意識到資源成本膨脹所帶來的壓力。等到業務到了必定規模，拿到機器帳單的時候，驚呼「機器怎麼這麼費錢」，再想當即下降成本，可能已經錯過了最佳時機，由於技術自己是一個相對長期的改造過程。

因此，正在閱讀此文的讀者，假如你已經感受到了成本膨脹的壓力，或者正在作成本控制相關的工做，恭喜，這是幸福的煩惱，貴公司的業務體量應該已經達到必定規模，同時也說明你的管理意識已經超前於業務發展了。

本文咱們將分享美團到餐研發團隊在資源成本優化方面的工做，經過近一年的實踐，下降了幾千萬的資源成本，取得了一些成就。

02實踐

在美團公司內，資源的提供方有多個團隊，除了到店餐飲研發團隊自用的資源外，還有多個兄弟團隊提供資源支持或者聯合共建，好比SRE、大數據團隊、風控團隊、廣告團隊等等。每月拿到成本帳單以後，咱們都須要抽絲剝繭，對每一項進行拆解，才能制定對應的解決策略。具體流程以下圖所示。

1. 肯定方法論

「凡事預則立，不預則廢。」在作一件事以前，要充分評估整個工做完整生命週期的要素，並進行總體工做框架的設計，一個科學的方法論是十分有必要的。成本優化遵循的是一個行業內成熟的P（Plan）D（Do）C（Check）A（Act）方法論，在每一個階段都又有對應的二次迭代和微循環。

在Plan或Standard階段要作的事：創建意識->肯定目標->分析現狀->肯定評價指標。

在Do執行階段要作的事：分解原子項目->肯定方案->落實到人->優化原子指標。

在Check檢查階段要作的事：規定動做檢查->行動結果評估->系統問題定位->修正標準動做。

在Act優化處理階段要作的事：按期覆盤->造成報告->迭代認知->升級方法論->下階段目標。

1. 計劃規劃階段（Plan&Standard）

在這個階段的核心目標是：用2-3個指標來衡量本身的工做。不少工做之因此最後失敗，不少時候是相關人員根本沒有辦法用具體可衡量的指標來衡量本身的工做，這樣對於工做結果，只能有一個「定性」的認識（好比很好，很不錯，很差，較差），而沒法作到「定量」。

對於研發人員來說，不能定量的結果是不夠科學的，具體如何肯定指標，或者肯定哪些指標做爲工做目標，其實也是一門學問（有機會另外發文章討論）。這個階段的幾個建議步驟爲：

創建意識。這個是團隊Leader的首要責任，要讓團隊成員明白本身在資源上花了多少錢，成本控制是否是一件真正有意義和價值的事，要作到你們認知一致。雖然見到過一些團隊在提倡成本控制，可是落實到具體行動時，卻流於形式或者無從下手，最後只能停留在口頭上，並無產生實際的效果。

肯定目標。這個過程相對宏觀，也能夠認爲是「定性」的階段。在這個階段要明確的就是，在成本控制這件事上，後續動做要解決的問題是什麼？好比有些團隊是整體成本偏高，但有些團隊總成本並不高，而是應該增長成本，有些團隊是非核心服務消耗的成本偏高，這些目標都須要通過團隊成員討論後獲得一致的結果。在後續階段的迭代中，也能夠進行不斷地修正。就像「客戶永遠不知道本身的需求」同樣，不少人是不清楚本身的目標的，可使用SMART原則來明確目標。

分析現狀。對成本這件事，羅列相關的數據，儘量多地幫助本身作判斷。本身團隊在成本優化這件事上，處在哪個階段，哪些工做有可能被進一步優化，在此階段要明確出來。

肯定評價指標。對於不一樣的專業序列，甚至對於同一專業序列的不一樣人員，你們對於成本的評價指標都不同。這個階段要作到最終的收斂，把團隊將來成本優化的結果，用明確的數據表示出來。好比在到餐研發團隊中，咱們確認了2個優化的核心指標：總成本、總訂單成本。後續你們全部努力的目標，若是跟這兩個指標沒有關係或者弱相關，均可以忽略。

本階段最大的經驗是「知易行難」，雖然拍腦殼想出來一兩個方向和目標很容易，可是最後用數據論證現狀時，如何判斷本身這個指標是「優秀」、「良好」仍是「不及格」？對標的團隊是誰？爲何對標的對象是TA？都是須要從人員規模、業務階段、業務量、行業特色等方面考慮仔細，也須要想清楚，其工做量甚至不比實際幹活階段小。

03執行階段（Do）

1.創建思考流程

在執行階段的流程是：分解原子項目->肯定方案->落實到人->優化原子指標。在這裏包括兩個核心要素：1）把核心指標相關的工做向下一層分解；2）在下一層，找到具體的人來執行，這我的要具有將本身負責的指標繼續分解到更細的能力，相似於咱們說的樹狀結構。這樣層層地分解下去，每一層的葉子節點均可以找到對應的負責人。這種「總分」結構，在一本經典教材《金字塔原理》中也有詳細的闡述。

分解原子項目。在本階段要創建一個徹底細化的分級結構，用金字塔原理中的"MECE不重不漏"原則，將工做內容分解到最細的可控粒度。至於按哪一個維度進行拆分，不一樣的團隊或者業務可能會有不一樣的原則，好比有些團隊直接按子團隊進行拆分，有些團隊按業務進行拆分，有些團隊按流程進行拆分。從較多團隊通用的角度，成本控制這件事，能夠簡單的將指標分解到二級指標，包括「自身使用的成本」和「被分攤的成本」。其中，「自身使用的成本」是指，爲了知足本身業務的須要，由本技術團隊申請或者使用資源產生的成本；「被分攤的成本」是指，因爲根據某種計算邏輯，間接使用了其餘團隊的資源，爲其餘技術團隊承擔一部分紅本費用，好比常見的資源包括公司其餘團隊開發的廣告、投放、風控、安全等系統。若是能夠分拆到具體的系統，則每一個系統又能夠繼續向下拆分到更細粒度的構成項目，每一個節點都是一個小的「總分」結構，按這個邏輯繼續向下分解，能夠分爲「可落地的最細粒度的成本」和「可落地的最細粒度的分攤成本」。

再根據開篇描述的方法，肯定每一個原子的評價指標，沒法量化的項目都是「耍流氓」。這樣就造成了一個更完整的金字塔結構，以下圖所示：

肯定方案。根據上面的金字塔結構，每一個原子指標，都須要專業的同窗來評價分析，肯定如何進行優化。好比，系統主機的成本，主要集中在虛擬機+存儲這樣的資源上，衡量的指標能夠肯定爲「資源利用率」和「單訂單成本」。爲了解決「資源利用率」這個原子指標，就須要考慮目前的空閒機器是否能夠下線，在線的服務是否能夠優化或者合併；爲了解決「單訂單成本」這個指標，能夠考慮分析下系統架構，跟核心流程處理有關的服務是否能夠更加高效或者抽象出來成爲服務中臺，這樣就能夠釋放一些"煙囪式"的建設資源，使得核心處理能力更加集中、高效。相似這樣將全部的解決方案整合起來，就造成了最後的解決方案。

落實到人。有了方案以後，必定要肯定惟一的Owner（主R），根據經驗，主R只有一個會比較好，不然會形成「責」、「權」、「利」分割不清。在這個過程當中，也是培養團隊技術能力和架構能力的好機會。

優化指標。不一樣的方案，實施的週期和代價不一樣，各個主R深刻到不一樣專業後，會對目前的資源指標有分析和反饋。有可能理論上全部的指標都須要優化，也有可能一些指標已經很好了，這時候要甄別出來哪些資源指標的實施「槓桿率」比較高。建議應用80/20原則進行分析，即某些指標投入20%的資源和精力能夠解決最後80%的核心問題，保證投入適合的工做量帶來較高的產出。對於沒有解決方案的資源或者實施難度過大的資源，建議果斷放棄或者擱置。

2.實踐分析框架

在具體實踐中，咱們能夠把以上的過程，再次用一個金字塔結構來表述，以下圖所示：

創建了以上的結構，就能夠根據各個專業的不一樣，對各自的指標進行優化了，若是最細一級的指標被成功優化以後，最上層的指標必定會有降低。由於上述指標都有其各自深層次的業務、技術，甚至是財務上的邏輯，故在此把一些須要關注的概念再贅述一下。

不少公司每一個技術團隊的機器成本，在財務上叫作「網站運維成本」（網站？聽起來還像PC時代的概念對不對），從頂層能夠分爲兩類構成因素，就是「本身產生的成本」（本身用的）和「被分攤的成本」（別人替你用的）兩大類。跟本身有關的繼續向下鑽取，能夠分爲交易相關的資源成本（跟業務流程相關的）以及跟分析有關的大數據成本（分析、算法、決策相關）。

（1）業務主機成本

大部分業務系統的團隊，使用的資源成本都包含在這個部分，好比商戶研發團隊、訂單系統研發團隊、前端研發團隊、供應鏈研發團隊、營銷系統研發團隊、CRM研發團隊等。這些資源典型的物理載體就是物理機、虛擬機、容器資源以及對應的機器鏈接的存儲（數據庫、緩存、KV存儲等）資源，還會包含因爲交換、存儲以上資源之間的數據產生的帶寬、雲資源、CDN等。

這部分資源，咱們從控制成本的角度，最淺的層次，建議關注服務組（OWT）所消耗主機的資源利用率，若是資源利用率較低的主機數量較多，建議及時下線。同時，從技術方案自己來講，任何一個服務承載的業務能力和消耗資源之間，會有相對的一個「比例」或者權重。某些高利用率的服務從架構上是否能夠重構、解耦或者改造，也很是有利於節省資源。這塊內容到餐研發團隊在過去一年的工做中，對於核心、非核心的服務都進行了梳理，對於其中能夠優化的服務也進行了部分重構。相比年初，極大的下降了資源的成本，業務主機成本的兩個主要指標變化狀況以下：

備註：後續因爲新增其餘業務致使成本略有上升

（2）大數據成本

大數據在互聯網行業的應用目前已經較爲成熟，行業主流的數據處理架構都是YARN 2.0或者相似框架，核心的資源消耗主要基於Container（Vcore+Mem）的計算資源+基於HDFS的存儲資源消耗這兩部分。

第一部分，是存儲資源的消耗，行業通用的模型是基於物理HDFS或自研的相似存儲引擎，這部分主要是指離線ETL用來按分區（通常是按時間戳）進行存儲的資源，因爲數據倉庫的核心理念之一是保存「全部」的數據，並在此基礎上按照維度建模理論對數據進行預彙總、加和。可是，因爲對模型建設自己的理解深度不一樣，故在基礎數據之上的數據冗餘，在不少數據研發人員看來是理所應當的，進而致使存儲資源的快速膨脹，這是每一個數據團隊在管理過程當中面臨的難題。

在此，到餐研發團隊主要採起了兩種手段：

a. 對於數據模型的熱度進行了分級，把數據分爲冷、溫、熱數據，對於須要保留的數據才保存在生產環境的HDD、SSD中，對於不重要的冷數據，經過異構的方式存入其餘介質中。

b. 對於數據模型自己，須要從新思考數據的價值和存儲，在數據的中間層（匯聚層），對數據模型進行重構，這也是不少數據團隊忽略的基本功部分。

到餐研發團隊對於數據倉庫進行了二次迭代，每次都基於新的業務模式，從新構建中間層以及之上的集市、寬表層，有效節省了空間。還有一種技術手段是壓縮，好比流量的數據每每是存儲大戶，可是流量數據相對的格式比較固定，因此不少流量數據能夠進行壓縮或者改變其存儲格式（如map型），根據實測能夠節省20%以上的流量數據空間。

另外須要補充的，還有一部分OLAP存儲資源，也會消耗大量資源，好比Kylin、Elasticsearch、Druid、MySQL等，這些數據庫主要用來將基於HDFS上的文件，同步到前端能夠直接訪問的介質上，供系統訪問。這部分資源有些也是基於HDFS的（如Kylin、HBase），有些須要單獨的存儲介質，也須要關注其膨脹速度以及存儲週期。

第二部分，是計算資源的消耗，主要知足基於複雜規則的分析或者機器學習算法中的計算，也就是實時ETL計算和離線ETL計算的場景（表明性的引擎如Storm、Flink的計算還有MapReduce的計算）。這部分計算消耗的資源相似於業務系統，能夠參照業務系統的「資源利用率」肯定幾個指標，進行機器優化或者算法邏輯優化。

（3）分攤成本（一）：風控及反爬

在某些公司裏，某個技術團隊開發的內容，有可能爲了服務其餘團隊業務，好比前文中提到的風控、反爬、廣告等，會爲各類業務提供基礎的技術能力。這時候就涉及到一個重要的概念「分攤」。分攤有兩種規則，一種是按「實際用量進行」，另一種是按照「使用比例」進行，這兩種模式之上，可能還有混合計費模式，即「按照實際發生的比例進行總體費用的分攤」。作成本控制時，就要清楚地知道這部分紅本是按哪一種邏輯來進行計算的。

在風控及反爬的實踐中，美團的風控及反爬按照總體風控技術團隊的整體成本，按比例分攤給業務團隊。因此做爲業務團隊，若是試圖下降這部分紅本，也要關注兩個組成項：一是本身使用的風控及反爬的原子業務數量的絕對值，對天天風控及反爬的整體請求次數是否合理須要進行判斷，以保證本身的業務請求量不增長；二是本身業務使用的比例。須要跟相關技術團隊一塊兒進行分析，以防止某些場景下，自身業務使用的絕對值降低了，可是由於其餘業務絕對值降低的更快，致使本身比例反而上升，進而致使成本上升。

（4）分攤成本（二）：安全數倉成本

爲了保證各個業務團隊之間的離線數據交換，美團集團層面建設了安全數據倉庫，用來知足跨團隊之間的數據交換。這部分的費用也按照實際發生的資源佔比進行統計，因此同理，爲了下降成本，須要關注兩個組成項目：一是本身使用的數量，從架構設計上可否將相關數據模型的效率提高、下降空間是關鍵因素；二是本身的使用資源在總體資源的佔比，這時候也須要跟相關團隊一塊兒努力下降總成本。不少公司的技術團隊，也有相似的數據共享倉庫或者共建倉庫的概念。

（5）分攤成本（三）：廣告成本

不少互聯網公司都有作廣告業務的技術團隊，廣告的形式主要有按點擊收費CPC，按時長收費CPT等等，這部分分攤的邏輯同上述二者，也是按最終的總費用中的佔比進行分攤。可是這塊有一個須要關注的點是，因爲廣告的業務邏輯並不在到餐本身的業務方，也就是說歸到餐研發團隊能夠控制的部分較小，故在這個過程當中須要創建有效的評價體系，來衡量廣告分攤的費用，在此採用的指標是「千次曝光成本」和「千元廣告收入成本」，這裏僅供你們參考。

（6）其餘成本

除了以上梳理的項目以外，每個月還會有一些新增的成本項目加入進來，團隊要保持足夠的關注。在實踐中會發現某項成本在個別月份忽然升高，這時候就要找到是新增長了項目，仍是某個指標在業務或者算法上有所調整。

04檢查（Check）

在這個階段，建議關注如下結果：

規定動做檢查。規定的方案是否執行？相關的同窗是否按照規定的動做進行了相對應的行動？這個階段只關注過程不關注結果，並且更多的是關注執行人、配合方、時間點，用項目管理的思路來運營。

結果評估。以前梳理出來的指標是否獲得了優化？這個過程是在驗證結果，各項指標中獲得優化和未優化的都要整理出詳細的List，有些指標如「資源利用率」是當即能夠查看結果的，有些結果是須要週期性的時間才能得到。在這個基礎上能夠繼續深刻反向思考，按「指標定義是否有問題->方案制定是否有問題->執行人是否有問題->配合方是否有問題」這個流程來進行評估。

系統問題定位。在這個過程當中，能夠作到小範圍閉環，建議針對某個指標的優化方案能夠設計多套，方案A不行立刻迭代成方案B，快速試錯，找到合理的方案。

修正標準動做。在執行的過程當中，不少方案和動做，都是在一線現場發現和修正的，不須要等待大規模覆盤的時候再提出問題和總結，主R要具有這樣的意識，在執行過程當中多說多問，找到關鍵要素，相信每一個同窗都有過這樣的經歷。經歷過某個完整項目生命週期的同窗，每每也是團隊內成長最快的骨幹。

在到餐研發團隊的實踐中，業務系統的指標定義上也有相似的經驗能夠分享。開始進行優化工做的時候，定義了很是多的的項目和指標，好比業務主機分爲雲存儲、帶寬、CDN、Tair、Redis等等，關注到每一項對於RD投入的時間和精力都是巨大的損耗。後來通過反覆跟相關兄弟團隊確認，向上抽象了一層「服務組的資源利用率」，這時候就不須要關注太多細碎的項目，而只關注與這些服務有關機器的使用狀況，由於機器會天然的消耗CPU、內存、帶寬、CDN等，這樣能夠有效節省運營的時間成本，把精力集中在優化機器和優化服務架構設計層面。

05覆盤總結，繼續迭代（Act）

按期覆盤。覆盤是一個很是重要的能力，我的覺得，覆盤總結的能力在某種程度上也表明了本身的「抽象能力+思考能力+管理能力」，關於覆盤的方法論書籍不少，這裏再也不進行贅述。在這個階段，我的建議關注的點在於兩個「知道」：「知道本身不知道」，經過覆盤掌握了成本優化的方法、框架、方案、團隊素質、結果；「不知道本身知道」，經過一些結果，知道了本身原來一直是在正確的道路上仍是在錯誤的道路上前進，把帶有「運氣」成分的成功，昇華成爲一種將來的「習慣性成功」。

造成報告。讓第一次看到這個報告的人，也能經過一兩次實踐，學會成本優化這件事。

迭代認知。將以前的過程開始深化和迭代，也是再次進行PDCA的過程，反覆打磨本身的抽象能力、思考能力、管理能力，使本身工做深度、廣度的ROI繼續提高。在迭代過程當中，總會有一些驚喜和收穫。從我的來講，原來覺得成本項目僅僅是個管理項目，在不斷經過技術手段取得成本優化的過程當中，收穫了對架構、技術的理解，而且不少時候須要用創新的手段來解決前人不曾突破的問題，另外還收穫了7項跟架構升級、數據壓縮、技術處理有關技術專利，也是技術能力提高的一個佐證。

06總結

成本優化這件事，有可能被階段性忽略，可是重要性一直存在。到餐研發團隊經過將近一年時間的運營，幫助公司節省了幾千萬的成本。這個過程有時候枯燥，有時候讓人興奮，有時候又讓人懊惱和沮喪，某些時候實際上是在拷問本身一個問題，即「保證業務不停的前提下，敢砍掉多餘的機器嗎？」在管理愈來愈精細化的今天，相信更多的有識之士也有一些需求或者進行了一些實踐。期待跟行業同儕一塊兒，在保證技術能力和知足業務的前提下，更加合理使用資源，節約公司成本，不斷提高研發團隊的效率。

不知道你們讀完本文是否有所啓發？6月21-23日，咱們邀請到了三位美團的講師參與GIAC峯會，爲咱們分享如下話題：

除美團講師外，組委會還邀請到了Google、微軟、Oracle、eBay、百度、阿里、騰訊、商湯、圖森、字節跳動、新浪等企業技術專家，圍繞互聯網架構最熱門的AI、大中臺、Cloud-Native、IoT、混沌工程、Fintech、數據及商業智能、工程文化及管理、經典架構等專題分享他們的實踐經驗、遇到的問題及解決方案。想了解大會更多案例，不妨識別圖中二維碼。此外，還有機會得到大會體驗票一張哦！