大型科技企業架構：中臺模式的愛與恨

大型企業面對快速變化的市場形勢，須要有像創業公司同樣快速的反應能力。然而因爲複雜的人員和層級關係，大企業作到「擁抱變化」是很困難的。

傳統以職能部門分治的樹狀組織架構，若一個底層員工有個好點子，就不得不自下而上說服管理層，管理層還需發動行政力量推進層層下屬，任何一環出了問題就難以進行，其難度可想而知。而各業務線各自有KPI，互相協做很是困難。

(傳統的組織架構)

即便說服老大，克服重重困難，從各部門抽調和招兵買馬，成立了新的業務部門。然而市場變化很是快，一旦業務受阻，方向轉換，花費巨大精力組成的業務線何去何從？此時部門的發展極大地依賴於老大的決策，底層活力不足。

大型組織想出各類方式解決這樣的問題，例如阿里在2016年提出了「大中臺小前臺」的戰略，將業務共同的工具和技術予以沉澱，成立專門的中臺部門。這樣新的項目能夠重用中臺服務而不用從新設計，避免重複功能建設和維護帶來的浪費和山頭林立。這樣作的不僅是企業，美軍更是設計了新的戰鬥方式，每3人一個小組，戰鬥須要時可隨時調集後方火力，信息和後勤支援，靈活而成本低廉。

程序員對這些概念更是熟悉，中臺類比到編程領域，就是造成可複用的函數庫，抽象共性，減小重複開發，提高迭代效率。中臺將人力，技術和服務從新組織，例如，數據中臺維護底層數據能力，內容中臺將各種資訊彙總整理，供給各業務線豐富的資訊資源；推薦營銷中臺抽象推薦系統的共性，爲各類業務提供營銷的快速接入能力。這樣也方便統一協調，如數據中臺可根據業務優先級管理流量和負載分配，這在各部門獨立運營時是不可想象的。固然，中臺還有一大好處：分擔風險，方便分黑鍋，你懂的。

固然，不是全部公司都能實現中臺戰略，中臺要求扁平化的管理模式，沒有太多的條條框框。靈活的考勤，沒有隔板的工位，統一的基礎設施（如數據庫和代碼庫），不然中臺就是空中樓閣，實施起來甚爲困難。

中臺模式的困擾

若是中臺模式所有都是好處，這篇文章就應該結束了。中臺相比於傳統模式雖有優點，但實踐和理論的隔閡必然存在。中臺該作不應作什麼，如何與業務方良好協同，如何評估KPI都成了難題。

咱們能夠根據中臺對業務方的參與度，繪製成下面的一張圖。

軸的最左邊：僅提供工具庫和少許答疑維護，不對業務效果負責。絕大多數開源項目，各類數據庫，均可以歸於這種極端。
軸的最右邊：all-in參與業務方的大部分流程，從運營業務，到數據模型，事無鉅細。咱們戲稱其爲「高級外包」。

咱們形象地稱其爲左傾和右傾問題。

越往左走，工具抽象和通用能力強，賦能業務多，雨露均沾，研發人員能專一於技術自己。但越往左越好麼？不必定。越左就沒法深刻業務場景，沒法接受業務滋養，極可能故步自封，甚至爲了技術而技術，變得學究派，而過於獨立的中臺變成了純後臺，更重要的是，如何評估業務產出？

在最右面則是另外一種極端，其優勢很是明顯：此時中臺徹底融入業務，有完整的業務sense，很是理解並能快速應對需求，與業務方打成一片，戲稱爲「高級外包」。可是，該模式的人力通常只能覆蓋單一業務，很難對外輻射。因爲精力所限，技術人員過度關注業務，中臺的技術深度就會相對較差。

咱們要同時警戒這兩種極端，但從總體來看，最容易被忽視的反而是右傾。右傾構建了看似美好的中臺合做模式，親密無間的服務，可是人們很容易忽略其問題：因爲過度具象和強耦合，中臺能力難以沉澱在通用的工具和理論上，當出現其餘相關業務時，原有產品並不能支持，應對變化的能力小，一旦業務方向變化就可能前功盡棄。

此時因爲中颱容量有限，太重的服務模式致使只能覆蓋有限的業務。中臺不得不評估前臺項目的重要程度，甚至拒絕爲低優先級的前臺提供支持，挑肥揀瘦。那麼前臺可能會爲本身的業績考慮去自行組團隊完成項目，進而致使中臺與前臺隔閡。相反的，若事無鉅細地參與到業務方，侵入性就會很強，人的問題會成爲最大的問題：它可能會架空業務方人員，引發猜疑，甚至可能被併入業務方，致使中臺骨幹流失。

那什麼纔是合理的中臺模式呢？

合理的中臺

最好的服務應該像空氣同樣，不留意就感覺不到存在，但不可或缺。

首先，中臺必須有對應領域過硬的能力積累，例如算法中臺須要有紮實的理論基礎，搜索中臺在搜索能力的積累更是要達到業務方遠達不到的程度。打鐵還需自身硬，不然被革命掉只是時間問題。

中臺一方面提供服務，另外一方面則促進人和人的交流，推進換位思考。本來不一樣方向的人爲了共同的任務在一塊兒工做，可以迅速地學習對方的能力。當任務告一段落後，咱們須要關注：業務方是否能維護，改進甚至優化中臺的工做和技術；中臺是否能產生對業務的通盤理解和技術沉澱。所以，在合做剛開始時，可適當右傾，中臺快速熟悉業務，創建共識；隨着業務深刻，業務方吸取消化，中臺逐漸後撤，直到業務方可自行處理大部分問題。

通常來講，在提供相同服務質量的前提下，對業務問題的抽象能力越好，參與度就能越往左。 例如SQL確實是很是偉大的發明，它將數據處理的需求抽象地如此淋漓盡致，技術人員可以專精於性能優化，業務方能靈活操做數據庫，完成業務任務。

所以，中臺有個重要命題應當考慮：本身的服務和技術應該如何合理抽象，將業務和底層儘量隔離開來？這套領域特定語言(DSL)應該如何設計，才能讓業務方也能看得懂，用得好？  Tensorflow和Keras這類深度學習框架成功的一大部分緣由，就是設計了很是良好的深度學習原語。越好的抽象和領域原語，就越能發揮前臺人員的業務優點和主觀能動性，極大地提高了溝通效率。

一樣，業務方也必須能把本身面臨的問題予以清晰地描述，參數，環境和目標至少能明白地寫在一張紙上。提出模糊的，太過抽象的(好比無論用什麼方式，只要能提高KPI)，甚至不切實際的目標，就是業務方的懶政和甩鍋，中臺不是高級外包。在任務層面上，兩邊應有清晰的分界和明確的問題，你們都精力有限，應作好份內之事。

在溝通上，不只須要主管之間的密切配合，創建緊密溝通機制，如按期參與前端的業務週會；同時還應有清晰的接口人機制。筆者見過很多例子：多個接口人致使信息冗雜，傳播不順暢，有時不得不十幾我的開大會，致使反覆溝通，效率很低。接口人須要明確業務問題，熟悉數據鏈路，溝通能力強，方能事半功倍。



結語

一切事業都須要由人來推進，大部分問題都是人的問題。組織形式的不一樣，會致使信息傳遞效率的極大不一樣，進而影響事業的成敗。「組織架構排名第二的公司，最後在市場上也只能居於老二的位置。」

本文只是筆者做爲某大型公司的基層中臺工程師，面對業務合做中遇到問題的一些思考，因爲視角限制，確定有以偏概全甚至偏激之處，還請各位讀者老爺海涵。爲何要寫這篇文章？由於研究如何利用零和博弈，組織一幫聰明人，高效地爲了同一個目標奮鬥是很是有意思的，組織架構的設計很值得思考。固然因爲篇幅所限，還有不少問題沒有討論，好比如何考覈中臺績效？

拿着 5000 塊的工資，操着 5000 億富豪的心吶。