研发团队资源成本优化实践
背景
工程師主要面對的是技術挑戰，更關注技術層面的目標。研發團隊的管理者則會把實現項目成果和業務需求作為核心目標。實際項目中，研發團隊所需資源（比如物理機器、內存、硬盤、網絡帶寬等）的成本，很容易被忽略，或者在很晚才考慮。
在一般情況下，如果要滿足更多的技術指標如并發量和復雜度等，或者滿足峰值業務的壓力，最直接有效的方法就是投入更多的資源。然而，從全局來看，如果資源成本缺乏優化，最終會出現如下圖所示的“邊際效用遞減”現象——技術能力的提升和資源的增幅并不匹配，甚至資源的膨脹速度會超過技術能力的提升，從而使技術項目本身的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研發團隊等。這些資源典型的物理載體就是物理機、虛擬機、容器資源以及對應的機器連接的存儲（DB、緩存、K-V數據庫等）資源，還會包含由于交換、存儲以上資源之間的數據產生的帶寬、云資源、CDN等。
這部分資源，我們從控制成本的角度，最淺的層次，建議關注服務組（OWT）所消耗主機的資源利用率，如果資源利用率較低的主機數量較多，建議及時下線。同時，從技術方案本身來說，任何一個服務承載的業務能力和消耗資源之間，會有相對的一個“比例”或者權重。某些高利用率的服務從架構上是否可以重構、解耦或者改造，也非常有利于節省資源。這塊內容到餐技術部在過去一年的工作中，對于核心、非核心的服務都進行了梳理，對于其中可以優化的服務也進行了部分重構。相比年初，很好的降低了資源的成本，業務主機成本的兩個主要指標的變化情況如下（備注，后續由于新增其他業務導致成本略有上升）：
3.2.2 大數據成本
數據行業在互聯網的應用目前已經較為成熟，行業主流的數據處理架構都是Yarn 2.0或者類似框架，核心的資源消耗主要基于Container（Vcore+Mem）的計算資源+基于HDFS的存儲資源消耗這兩部分：
第一部分，是存儲資源的消耗，行業通用的模型是基于物理HDFS或自研的類似存儲引擎，這部分主要是指離線ETL用來按分區（一般是按時間戳）進行存儲的資源，由于數據倉庫的核心理念之一是保存“所有”的數據，并在此基礎上按照維度建模理論對數據進行預匯總、加和。但是，由于對于模型建設本身的理解深度不同，故在基礎數據之上的數據冗余，在很多數據研發人員看來是理所應當的，進而導致存儲資源的快速膨脹，這是每個數據團隊在管理過程中面臨的難題。
在此，到餐研發團隊主要采取了兩種手段：
到餐數據團隊對于數據倉庫進行了二次迭代，每次都基于新的業務模式，重新構建中間層以及之上的集市、寬表層，有效節省了空間。還有一種技術手段是壓縮，比如流量的數據往往是存儲大戶，但是流量數據相對的格式比較固定，所以很多流量數據可以進行壓縮或者改變其存儲格式（如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)
- 定期復盤。復盤是一個非常重要的能力，個人以為，復盤總結的能力在某種程度上也代表了自己的“抽象能力+思考能力+管理能力”，關于復盤的方法論書籍很多，這里不再進行贅述。在這個階段，個人建議關注的點在于兩個“知道”：“知道自己不知道”，通過復盤掌握了成本優化的方法、框架、方案、團隊素質、結果；“不知道自己原來知道”，通過一些結果，知道了自己原來一直是在正確的道路上還是在錯誤的道路上前進，把帶有“運氣”成分的成功，升華成為一種未來的“習慣性成功”。
- 形成報告。讓第一次看到這個報告的人，也能通過1-2次實踐，學會成本優化這件事。
- 迭代認知。將之前的過程開始深化和迭代，也是再次進行PDCA的過程，反復打磨自己的抽象能力、思考能力、管理能力，使自己工作深度、廣度的ROI繼續提升。在迭代過程中，總會有一些驚喜和收獲。從個人來說，原來以為成本項目僅僅是個管理項目，在不斷通過技術手段取得成本優化的過程中，收獲了對架構、技術的理解，并且很多時候需要用創新的手段來解決前人未曾突破的問題，另外還收獲了7項跟架構升級、數據壓縮、技術處理有關技術專利，也是技術能力提升的一個佐證。
總結
成本優化這件事，有可能被階段性忽略，但是重要性一直存在。到餐研發團隊通過將近一年時間的運營，幫助公司節省了幾千萬的成本。這個過程有時候枯燥，有時候讓人興奮，有時候又讓人懊惱和沮喪，某些時候其實是在拷問自己一個問題：“保證業務不停的前提下，敢砍掉多余的機器嗎？”在管理越來越精細化的今天，相信更多的有識之士也有一些需求或者進行了一些實踐。期待跟行業同儕一起，在保證技術能力和滿足業務的前提下，更加合理使用資源，節約公司成本，不斷提升研發團隊的效率，希望本文能給大家帶來一些啟發。
作者簡介
- 劉強，美團到店餐飲研發中心數據方向負責人，美團數據技術通道委員，2017年入職美團點評，就職于到店餐飲研發中心，負責到餐數據倉庫、數據產品、數據系統的研發工作。之前曾任多家公司的數據方向負責人。
- 建鐘、小英、楊軒、云杰、方旭、鵬文，均為美團到餐研發團隊工程師，對本文均有貢獻。
特別感謝
在本文及成本優化過程中，得到了美團技術團隊李偉、任登君、李聞、謝語宸、洪丹、左普存、郭樹熠、刁士涵等人的支持和幫助，在此表示感謝！
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的研发团队资源成本优化实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： AI Challenger 2018：细
- 下一篇： Redux从设计到源码