背景
工程師主要面對的是技術挑戰，更關注技術層面的目標。研發團隊的管理者則會把實現專案成果和業務需求作為核心目標。實際專案中，研發團隊所需資源（比如物理機器、記憶體、硬碟、網路頻寬等）的成本，很容易被忽略，或者在很晚才考慮。
在一般情況下，如果要滿足更多的技術指標如併發量和複雜度等，或者滿足峰值業務的壓力，最直接有效的方法就是投入更多的資源。然而，從全域性來看，如果資源成本缺乏最佳化，最終會出現如下圖所示的“邊際效用遞減”現象——技術能力的提升和資源的增幅並不匹配，甚至資源的膨脹速度會超過技術能力的提升，從而使技術專案本身的ROI大打折扣。
從筆者十餘年的工作經驗來看，資源成本最佳化宜早不宜遲。很多管理者在業務發展的較前期階段，可能並沒有意識到資源成本膨脹所帶來的壓力。等到業務到了一定規模，拿到機器賬單的時候，驚呼“機器怎麼這麼費錢”，再想立即降低成本，可能已經錯過了最佳時機，因為技術本身是一個相對長期的改造過程。
所以，正在閱讀此文的讀者，假如你已經感覺到了成本膨脹的壓力，或者正在做成本控制相關的工作，恭喜，這是幸福的煩惱，貴公司的業務體量應該已經達到一定規模，同時也說明你的管理意識已經超前於業務發展了（握手）。
本文我們將分享美團到餐研發團隊在資源成本最佳化方面的工作，透過近一年的實踐，降低了幾千萬的資源成本，取得了一些成就。
實踐
在美團公司內，資源的提供方有多個團隊，除了到店餐飲研發團隊自用的資源外，還有多個兄弟團隊提供資源支援或者聯合共建，比如SRE、大資料團隊、風控團隊、廣告團隊等等。每個月拿到成本賬單之後，我們都需要抽絲剝繭，對每一項進行拆解，才能制定對應的解決策略。具體流程如下圖所示。
1. 確定方法論
“凡事預則立，不預則廢。”在做一件事之前，要充分評估整個工作完整生命週期的要素，並進行整體工作框架的設計，一個科學的方法論是十分有必要的。成本最佳化遵循的是一個行業內成熟的P（Plan）D（Do）C（Check）A（Act）方法論，在每個階段都又有對應的二次迭代和微迴圈。
在Plan或Standard階段要做的事：建立意識->確定目標->分析現狀->確定評價指標。
在Do執行階段要做的事：分解原子專案->確定方案->落實到人->最佳化原子指標。
在Check檢查階段要做的事：規定動作檢查->行動結果評估->系統問題定位->修正標準動作。
在Act最佳化處理階段要做的事：定期覆盤->形成報告->迭代認知->升級方法論->下階段目標。
2. 計劃規劃階段（Plan&Standard）
在這個階段的核心目標是：用2-3個指標來衡量自己的工作。很多工作之所以最後失敗，很多時候是相關人員根本沒有辦法用具體可衡量的指標來衡量自己的工作，這樣對於工作結果，只能有一個“定性”的認識（比如很好，很不錯，不好，較差），而無法做到“定量”。
對於研發人員來講，不能定量的結果是不夠科學的，具體如何確定指標，或者確定哪些指標作為工作目標，其實也是一門學問（有機會另外發文章討論）。這個階段的幾個建議步驟為：
建立意識。這個是團隊Leader的首要責任，要讓團隊成員明白自己在資源上花了多少錢，成本控制是不是一件真正有意義和價值的事，要做到大家認知一致。雖然見到過一些團隊在提倡成本控制，但是落實到具體行動時，卻流於形式或者無從下手，最後只能停留在口頭上，並沒有產生實際的效果。
確定目標。這個過程相對宏觀，也可以認為是“定性”的階段。在這個階段要明確的就是，在成本控制這件事上，後續動作要解決的問題是什麼？比如有些團隊是總體成本偏高，但有些團隊總成本並不高，而是應該增加成本，有些團隊是非核心服務消耗的成本偏高，這些目標都需要經過團隊成員討論後得到一致的結果。在後續階段的迭代中，也可以進行不斷地修正。就像“客戶永遠不知道自己的需求”一樣，很多人是不清楚自己的目標的，可以使用SMART原則來明確目標。
分析現狀。對成本這件事，羅列相關的資料，儘可能多地幫助自己做判斷。自己團隊在成本最佳化這件事上，處在哪一個階段，哪些工作有可能被進一步最佳化，在此階段要明確出來。
確定評價指標。對於不同的專業序列，甚至對於同一專業序列的不同人員，大家對於成本的評價指標都不一樣。這個階段要做到最終的收斂，把團隊未來成本最佳化的結果，用明確的資料表示出來。比如在到餐研發團隊中，我們確認了2個最佳化的核心指標：總成本、總訂單成本。後續大家所有努力的目標，如果跟這兩個指標沒有關係或者弱相關，都可以忽略。
本階段最大的經驗是“知易行難”，雖然拍腦袋想出來一兩個方向和目標很容易，但是最後用資料論證現狀時，如何判斷自己這個指標是“優秀”、“良好”還是“不及格”？對標的團隊是誰？為什麼對標的物件是TA？都是需要從人員規模、業務階段、業務量、行業特點等方面考慮仔細，也需要想清楚，其工作量甚至不比實際幹活階段小。
3. 執行階段（Do）
3.1 建立思考流程
在執行階段的流程是：分解原子專案->確定方案->落實到人->最佳化原子指標。在這裡包括兩個核心要素：1）把核心指標相關的工作向下一層分解；2）在下一層，找到具體的人來執行，這個人要具備將自己負責的指標繼續分解到更細的能力，類似於我們說的樹狀結構。這樣層層地分解下去，每一層的葉子節點都可以找到對應的負責人。這種“總分”結構，在一本經典教材《金字塔原理》中也有詳細的闡述。
分解原子專案。在本階段要建立一個完全細化的分級結構，用金字塔原理中的"MECE不重不漏"原則，將工作內容分解到最細的可控粒度。至於按哪個維度進行拆分，不同的團隊或者業務可能會有不同的原則，比如有些團隊直接按子團隊進行拆分，有些團隊按業務進行拆分，有些團隊按流程進行拆分。從較多團隊通用的角度，成本控制這件事，可以簡單的將指標分解到二級指標，包括“自身使用的成本”和“被分攤的成本”。其中，“自身使用的成本”是指，為了滿足自己業務的需要，由本技術團隊申請或者使用資源產生的成本；“被分攤的成本”是指，由於根據某種計算邏輯，間接使用了其他團隊的資源，為其他技術團隊承擔一部分成本費用，比如常見的資源包括公司其他團隊開發的廣告、投放、風控、安全等系統。如果可以分拆到具體的系統，則每個系統又可以繼續向下拆分到更細粒度的構成專案，每個節點都是一個小的“總分”結構，按這個邏輯繼續向下分解，可以分為“可落地的最細粒度的成本”和“可落地的最細粒度的分攤成本”。
再根據開篇描述的方法，確定每個原子的評價指標，無法量化的專案都是“耍流氓”。這樣就形成了一個更完整的金字塔結構，如下圖所示：
確定方案。根據上面的金字塔結構，每個原子指標，都需要專業的同學來評價分析，確定如何進行最佳化。比如，系統主機的成本，主要集中在虛擬機器+儲存這樣的資源上，衡量的指標可以確定為“資源利用率”和“單訂單成本”。為了解決“資源利用率”這個原子指標，就需要考慮目前的空閒機器是否可以下線，線上的服務是否可以最佳化或者合併；為了解決“單訂單成本”這個指標，可以考慮分析下系統架構，跟核心流程處理有關的服務是否可以更加高效或者抽象出來成為服務中臺，這樣就可以釋放一些"煙囪式"的建設資源，使得核心處理能力更加集中、高效。類似這樣將所有的解決方案整合起來，就形成了最後的解決方案。
落實到人。有了方案之後，一定要確定唯一的Owner（主R），根據經驗，主R只有一個會比較好，否則會造成“責”、“權”、“利”分割不清。在這個過程中，也是培養團隊技術能力和架構能力的好機會。
最佳化指標。不同的方案，實施的週期和代價不同，各個主R深入到不同專業後，會對目前的資源指標有分析和反饋。有可能理論上所有的指標都需要最佳化，也有可能一些指標已經很好了，這時候要甄別出來哪些資源指標的實施“槓桿率”比較高。建議應用80/20原則進行分析，即某些指標投入20%的資源和精力可以解決最後80%的核心問題，保證投入適合的工作量帶來較高的產出。對於沒有解決方案的資源或者實施難度過大的資源，建議果斷放棄或者擱置。
3.2 實踐分析框架
在具體實踐中，我們可以把以上的過程，再次用一個金字塔結構來表述，如下圖所示：
建立了以上的結構，就可以根據各個專業的不同，對各自的指標進行最佳化了，如果最細一級的指標被成功最佳化之後，最上層的指標一定會有下降。因為上述指標都有其各自深層次的業務、技術，甚至是財務上的邏輯，故在此把一些需要關注的概念再贅述一下。
很多公司每個技術團隊的機器成本，在財務上叫做“網站運維成本”（網站？聽起來還像PC時代的概念對不對），從頂層可以分為兩類構成因素，就是“自己產生的成本”（自己用的）和“被分攤的成本”（別人替你用的）兩大類。跟自己有關的繼續向下鑽取，可以分為交易相關的資源成本（跟業務流程相關的）以及跟分析有關的大資料成本（分析、演算法、決策相關）。
3.2.1 業務主機成本
大部分業務系統的團隊，使用的資源成本都包含在這個部分，比如商戶研發團隊、訂單系統研發團隊、前端研發團隊、供應鏈研發團隊、營銷系統研發團隊、CRM研發團隊等。這些資源典型的物理載體就是物理機、虛擬機器、容器資源以及對應的機器連線的儲存（資料庫、快取、KV儲存等）資源，還會包含由於交換、儲存以上資源之間的資料產生的頻寬、雲資源、CDN等。
這部分資源，我們從控制成本的角度，最淺的層次，建議關注服務組（OWT）所消耗主機的資源利用率，如果資源利用率較低的主機數量較多，建議及時下線。同時，從技術方案本身來說，任何一個服務承載的業務能力和消耗資源之間，會有相對的一個“比例”或者權重。某些高利用率的服務從架構上是否可以重構、解耦或者改造，也非常有利於節省資源。這塊內容到餐研發團隊在過去一年的工作中，對於核心、非核心的服務都進行了梳理，對於其中可以最佳化的服務也進行了部分重構。相比年初，極大的降低了資源的成本，業務主機成本的兩個主要指標變化情況如下：
3.2.2 大資料成本
大資料在網際網路行業的應用目前已經較為成熟，行業主流的資料處理架構都是YARN 2.0或者類似框架，核心的資源消耗主要基於Container（Vcore+Mem）的計算資源+基於HDFS的儲存資源消耗這兩部分。
第一部分，是儲存資源的消耗，行業通用的模型是基於物理HDFS或自研的類似儲存引擎，這部分主要是指離線ETL用來按分割槽（一般是按時間戳）進行儲存的資源，由於資料倉儲的核心理念之一是儲存“所有”的資料，並在此基礎上按照維度建模理論對資料進行預彙總、加和。但是，由於對模型建設本身的理解深度不同，故在基礎資料之上的資料冗餘，在很多資料研發人員看來是理所應當的，進而導致儲存資源的快速膨脹，這是每個資料團隊在管理過程中面臨的難題。
在此，到餐研發團隊主要採取了兩種手段：
對於資料模型的熱度進行了分級，把資料分為冷、溫、熱資料，對於需要保留的資料才儲存在生產環境的HDD、SSD中，對於不重要的冷資料，透過異構的方式存入其他介質中。
對於資料模型本身，需要重新思考資料的價值和儲存，在資料的中間層（匯聚層），對資料模型進行重構，這也是很多資料團隊忽略的基本功部分。
到餐研發團隊對於資料倉儲進行了二次迭代，每次都基於新的業務模式，重新構建中間層以及之上的集市、寬表層，有效節省了空間。還有一種技術手段是壓縮，比如流量的資料往往是儲存大戶，但是流量資料相對的格式比較固定，所以很多流量資料可以進行壓縮或者改變其儲存格式（如map型），根據實測可以節省20%以上的流量資料空間。
另外需要補充的，還有一部分OLAP儲存資源，也會消耗大量資源，比如Kylin、Elasticsearch、Druid、MySQL等，這些資料庫主要用來將基於HDFS上的檔案，同步到前端可以直接訪問的介質上，供系統訪問。這部分資源有些也是基於HDFS的（如Kylin、HBase），有些需要單獨的儲存介質，也需要關注其膨脹速度以及儲存週期。
第二部分，是計算資源的消耗，主要滿足基於複雜規則的分析或者機器學習演算法中的計算，也就是實時ETL計算和離線ETL計算的場景（代表性的引擎如Storm、Flink的計算還有MapReduce的計算）。這部分計算消耗的資源類似於業務系統，可以參照業務系統的“資源利用率”確定幾個指標，進行機器最佳化或者演算法邏輯最佳化。
3.2.3 分攤成本（一）：風控及反爬
在某些公司裡，某個技術團隊開發的內容，有可能為了服務其他團隊業務，比如前文中提到的風控、反爬、廣告等，會為各種業務提供基礎的技術能力。這時候就涉及到一個重要的概念“分攤”。分攤有兩種規則，一種是按“實際用量進行”，另外一種是按照“使用比例”進行，這兩種模式之上，可能還有混合計費模式，即“按照實際發生的比例進行整體費用的分攤”。做成本控制時，就要清楚地知道這部分成本是按哪種邏輯來進行計算的。
在風控及反爬的實踐中，美團的風控及反爬按照整體風控技術團隊的總體成本，按比例分攤給業務團隊。所以作為業務團隊，如果試圖降低這部分成本，也要關注兩個組成項：一是自己使用的風控及反爬的原子業務數量的絕對值，對每天風控及反爬的總體請求次數是否合理需要進行判斷，以保證自己的業務請求量不增加；二是自己業務使用的比例。需要跟相關技術團隊一起進行分析，以防止某些場景下，自身業務使用的絕對值下降了，但是因為其他業務絕對值下降的更快，導致自己比例反而上升，進而導致成本上升。
3.2.4 分攤成本（二）：安全數倉成本
為了保證各個業務團隊之間的離線資料交換，美團集團層面建設了安全資料倉儲，用來滿足跨團隊之間的資料交換。這部分的費用也按照實際發生的資源佔比進行統計，所以同理，為了降低成本，需要關注兩個組成專案：一是自己使用的數量，從架構設計上能否將相關資料模型的效率提升、降低空間是關鍵因素；二是自己的使用資源在整體資源的佔比，這時候也需要跟相關團隊一起努力降低總成本。很多公司的技術團隊，也有類似的資料共享倉庫或者共建倉庫的概念。
3.2.5 分攤成本（三）：廣告成本
很多網際網路公司都有做廣告業務的技術團隊，廣告的形式主要有按點選收費CPC，按時長收費CPT等等，這部分分攤的邏輯同上述兩者，也是按最終的總費用中的佔比進行分攤。但是這塊有一個需要關注的點是，由於廣告的業務邏輯並不在到餐自己的業務方，也就是說歸到餐研發團隊可以控制的部分較小，故在這個過程中需要建立有效的評價體系，來衡量廣告分攤的費用，在此採用的指標是“千次曝光成本”和“千元廣告收入成本”，這裡僅供大家參考。
3.2.6 其他成本
除了以上梳理的專案之外，每月還會有一些新增的成本專案加入進來，團隊要保持足夠的關注。在實踐中會發現某項成本在個別月份突然升高，這時候就要找到是新增加了專案，還是某個指標在業務或者演算法上有所調整。
4. 檢查（Check）
在這個階段，建議關注以下結果：
規定動作檢查。規定的方案是否執行？相關的同學是否按照規定的動作進行了相對應的行動？這個階段只關注過程不關注結果，而且更多的是關注執行人、配合方、時間點，用專案管理的思路來運營。
結果評估。之前梳理出來的指標是否得到了最佳化？這個過程是在驗證結果，各項指標中得到最佳化和未最佳化的都要整理出詳細的List，有些指標如“資源利用率”是立即可以檢視結果的，有些結果是需要週期性的時間才能獲得。在這個基礎上可以繼續深入反向思考，按“指標定義是否有問題->方案制定是否有問題->執行人是否有問題->配合方是否有問題”這個流程來進行評估。
系統問題定位。在這個過程中，可以做到小範圍閉環，建議針對某個指標的最佳化方案可以設計多套，方案A不行馬上迭代成方案B，快速試錯，找到合理的方案。
修正標準動作。在執行的過程中，很多方案和動作，都是在一線現場發現和修正的，不需要等待大規模覆盤的時候再提出問題和總結，主R要具備這樣的意識，在執行過程中多說多問，找到關鍵要素，相信每個同學都有過這樣的經歷。經歷過某個完整專案生命週期的同學，往往也是團隊內成長最快的骨幹。
在到餐研發團隊的實踐中，業務系統的指標定義上也有類似的經驗可以分享。開始進行最佳化工作的時候，定義了非常多的的專案和指標，比如業務主機分為雲端儲存、頻寬、CDN、Tair、Redis等等，關注到每一項對於RD投入的時間和精力都是巨大的損耗。後來經過反覆跟相關兄弟團隊確認，向上抽象了一層“服務組的資源利用率”，這時候就不需要關注太多細碎的專案，而只關注與這些服務有關機器的使用情況，因為機器會自然的消耗CPU、記憶體、頻寬、CDN等，這樣可以有效節省運營的時間成本，把精力集中在最佳化機器和最佳化服務架構設計層面。
5. 覆盤總結，繼續迭代（Act）
定期覆盤。覆盤是一個非常重要的能力，個人以為，覆盤總結的能力在某種程度上也代表了自己的“抽象能力+思考能力+管理能力”，關於覆盤的方法論書籍很多，這裡不再進行贅述。在這個階段，個人建議關注的點在於兩個“知道”：“知道自己不知道”，透過覆盤掌握了成本最佳化的方法、框架、方案、團隊素質、結果；“不知道自己知道”，透過一些結果，知道了自己原來一直是在正確的道路上還是在錯誤的道路上前進，把帶有“運氣”成分的成功，昇華成為一種未來的“習慣性成功”。
形成報告。讓第一次看到這個報告的人，也能透過一兩次實踐，學會成本最佳化這件事。
迭代認知。將之前的過程開始深化和迭代，也是再次進行PDCA的過程，反覆打磨自己的抽象能力、思考能力、管理能力，使自己工作深度、廣度的ROI繼續提升。在迭代過程中，總會有一些驚喜和收穫。從個人來說，原來以為成本專案僅僅是個管理專案，在不斷透過技術手段取得成本最佳化的過程中，收穫了對架構、技術的理解，並且很多時候需要用創新的手段來解決前人未曾突破的問題，另外還收穫了7項跟架構升級、資料壓縮、技術處理有關技術專利，也是技術能力提升的一個佐證。
總結
成本最佳化這件事，有可能被階段性忽略，但是重要性一直存在。到餐研發團隊透過將近一年時間的運營，幫助公司節省了幾千萬的成本。這個過程有時候枯燥，有時候讓人興奮，有時候又讓人懊惱和沮喪，某些時候其實是在拷問自己一個問題，即“保證業務不停的前提下，敢砍掉多餘的機器嗎？”在管理越來越精細化的今天，相信更多的有識之士也有一些需求或者進行了一些實踐。期待跟行業同儕一起，在保證技術能力和滿足業務的前提下，更加合理使用資源，節約公司成本，不斷提升研發團隊的效率，希望本文能給大家帶來一些啟發。
作者簡介
劉強，美團到店餐飲研發中心資料方向負責人，美團技術委員會資料技術通道委員，2017年入職美團點評，就職於到店餐飲研發中心，負責到餐資料倉儲、資料產品、資料系統的研發工作。之前曾任多家公司的資料方向負責人。
建鍾、小英、楊軒、雲傑、方旭、鵬文，均為美團到餐研發團隊的工程師，對本文均有貢獻。