當技術為組織所累時怎麼辦？將你的組織架構旋轉90度！

作者｜楊波

編輯｜小智

作者近期針對企業數字化和架構轉型思考後陸續寫了三篇文章，這篇是第二篇，主題專註組織架構轉型，前一篇稱為《企業的組織架構是如何影響技術架構的？》，主題是建立背景上下文 (background)，最後一篇稱為《大規模生產級微服務的關鍵支撐技術》，主題關於微服務架構和 DevOps 關鍵支撐技術，讀者可以關注 InfoQ 公眾號等待後續更新。

一、理想 vs 現實

根據 2016 年 DevOps 發展報告 [附錄 1]：高效組織比低效組織的發布頻率高 200 倍，交付周期快 2555 倍，故障恢復時間快 24 倍，變更失敗率低 3 倍。

DevOps 發展報告令人鼓舞，但是理想很豐滿，現實很骨幹，目前大多數 (尤其是成長型) 技術組織的現狀卻令人堪憂，他們的不僅交付能力遠遠達不到高效能組織的水平，而且還深陷各種困局：

方輪子困局 (Too Busy To Improve)

組織普遍存在「Too busy to improve」的惡性循環 (downward spiral)，下面是常見的場景：

業務壓得喘不過氣

系統耦合歷史負擔重

老系統還要升級（換輪子）

工程師質量參差不齊

機房容量剛好又不夠，還得搬家遷機房

這麼多事情湊在一塊難免還要出故障

一出故障被老闆挑戰更加束手不敢試錯

穀倉 (Silo) 困局

穀倉在國內也被稱為煙囪或者豎井，通常出現在嚴格職能型組織中，表現為職能團隊間信任不足，合作欠佳摩擦不斷，各職能團隊像一個個嚴實林立的穀倉一樣，故而得名。下面是一個典型的場景：

業務領導：我們的增長太慢了，為啥我們不能比競爭對手更快推出產品？

產品管理：技術團隊不給力，大量需求堆積無法推進，技術的問題怪不了我們！

研發團隊：沒有按時交付項目不能怪我們，我們要求的機器運維一直拖著沒有到位，運維的老大該換換了！

運維團隊：客戶都快氣瘋了，我們大部分時間在救火保障系統穩定性，不要再扔東西給我們了，我的團隊都快跑光了…

影子 IT 和「穀倉式」系統建設

當研發不給力，無法滿足業務團隊的交付要求時，業務團隊傾向於自立門戶，成立獨立的研發團隊，有的甚至會另起爐灶，自建獨立的技術甚至運維體系。因為相關團隊遊離於正常研發之外，直接彙報給業務線，所以也稱為影子 (shadow)IT。影子 IT 相當於再造一個「穀倉」，對企業造成的「損害」包括：

重複功能建設和維護帶來的重複投資

打通「穀倉」系統間交互的集成和協作成本高昂

不利於業務的沉澱和持續發展

阿里巴巴發展的早期經歷過很多次「穀倉」式的系統建設，詳見附錄 [7]。

注意，影子 IT 並非只有弊端，也可能帶來意外的競爭激勵和創新。

項目制的弊端

目前大部分研發組織仍然採用傳統的項目制研發模式，研發人員跟著項目走，一個項目剛做完，很快會被安排到一個新的項目上重新開始。若干個項目下來，研發人員的項目經驗會增長，但是普遍沒有產品歸屬感 (ownership)，無法形成業務領域知識沉澱，簡單講就是不通業務。長期會造成研發人員工作積極性和創造性下降，跳槽頻繁穩定性低的問題。顧問型和外包型公司大多是項目制的，類似問題尤其明顯。

技術驅動 vs 業務驅動的陷阱

大部分技術組織對外宣傳都稱自己是技術驅動的，但是在業務和技術分離的職能型組織中，實際情況是技術部門根本談不上驅動，頂多是支持，有的還常是背鍋的角色。道理很簡單，一方面業務方在董事會上肯定比技術方更擅長高談闊論和畫餅，更容易獲得老闆的好感；另一方面，交付效率和系統穩定性最終靠下游的技術方落地，這些東西是老闆能直接感知的，一出問題，業務方在上游是比較容易轉移注意力的，最後背鍋的自然是下游的技術方。技術方加班加點一般都無怨言，但是輪到背鍋卻是有苦說不出。

開發和運維之間的緊張關係

在開發和運維分離的嚴格職能型組織中，雙方的 KPI 目標常不一致甚至是衝突的：

開發要更多更快的交付新功能，要變更；

運維則要儘可能保證現有系統的穩定性，不要變更。

目標衝突造成雙方的天然緊張關係。

二、原理

系統制約原理

W.Edwards Deming 曾指出 [附錄 9]，It is the system, not the people working in the system that determines a systems performance，系統的性能主要由系統本身決定的，而不是系統中工作的個人。

Deming 認為，在給定的上下文 (系統組織) 中，個人一般會自激勵盡最大努力做到最好。但如果系統本身設置是有問題，則會極大制約系統內部個人的發揮。所以，針對上述困局，我們不能簡單責備系統中的個人，而是應該跳出來從系統組織緯度去思考和調整，才可能找到根本性的解決之道。

康威法則

Melvin Conway 在 1967 年提出所謂康威法則 [附錄 8]，指出組織架構和系統架構之間有一種隱含的映射關係：

Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization. 設計系統的組織其產生的設計等價於組織間的溝通結構。

康威法則給我們的啟示：軟體系統的介面結構會映射組織的溝通結構，如果組織架構不合理，就無法建立一個高效的系統架構。一般在系統架構調整時，要提前考慮相應的組織架構的調整，兩邊聯動才能產生效果。詳見 [附錄 12]。康威法則是近年流行的微服務架構背後的組織原理。

DevOps 原理

IT 運維管理暢銷書《鳳凰項目》[附錄 13] 的作者 Gene Kim 在調研了眾多高效能 IT 組織後總結出支撐 DevOps 運作的三個原理 (The Three Ways: The Principles Underpinning DevOps)[附錄 2]，見下圖：

原理一：系統思考 (System Thinking)

開發驅動的組織，其能力不是製作軟體，而是持續的交付客戶價值。價值從業務需求開始，經過研發測試，到部署運維，依次流動，並最終以服務形式交付到客戶手中。整個價值鏈流速並不依賴單個部分 (團隊或個人) 的傑出工作，而是受整個價值鏈最薄弱環節 (瓶頸) 的限制。所以局部優化通常無效，反而招致全局受損。

Gene Kim 特別指出：Any improvements made anywhere besides the bottleneck are an illusion. 在瓶頸之外的任何優化提升都只是幻象。

系統思考要求我們加強團隊合作，培養流式思維和瓶頸約束意識，優先找出瓶頸並針對性地優化。

原理二：強化反饋環 (Amplify Feedback Loops)

過程改進常通過加強反饋環來達成。原理二強調企業和客戶之間、組織團隊間、流程上和系統內的反饋環。沒有測量就沒有提升，反饋要以測量數據為準，通過數據優化改進系統。

原理三：持續試驗和學習的文化 (Culture of Continual Experimentation And Learning)

在企業管理文化層面強調勇於試錯、持續試驗、學習和改進的文化。

三、組織架構轉型

傳統職能式組織 vs 現代跨職能微服務組織

Adrian Cockcorft 是前 Netflix 雲架構師，在經歷 Netflix 大規模微服務架構的成功實踐後，他提議現代組織要打破穀倉式職能壁壘，擁抱基於微服務的跨職能產品團隊組織模式 [附錄 3]。

目前大部分研發組織仍嚴格劃分職能，職能間交集少，如下圖所示。標準的研發流程以產品經理和研發團隊 (包括用戶體驗團隊) 反覆多次討論新功能需求開始；研發團隊再將新功能用代碼實現；然後代碼被提交質量保證團隊進行測試，這中間又涉及雙方的多次會議交互；測試通過後提交 DBA 和運維上線，這中間又涉及和 DBA、系統、網路和存儲管理員的多次交互 (一般通過工單系統)。整個流程緩慢充滿各種會議協調開銷。

有些組織會更進一步組織端到端的跨職能產品研發團隊，如下圖，這種組織模式能夠在團隊內形成反饋閉環，交互溝通開銷小。但是如果系統架構仍然是單塊的，根據康威法則，組織架構和系統架構不匹配，就無法避免單塊交付模式必然存在的跨團隊協作溝通（例如多團隊協調集成回歸測試）和交付件傳遞 (hand-offs) 問題，整體效率仍然受限，無法達成真正的敏捷。

康威法則告訴我們，軟體系統的介面結構會反映組織的社交結構。所以如果組織要真正轉型到微服務架構，就必須圍繞微服務產品組織團隊，基於 DevOps 模式開展工作。組織內不再以流水線方式設置產品經理，用戶體驗經理，研發經理等獨立職能角色。每個核心產品 (實現為微服務) 有一個經理，即負責管理和監督團隊，也負責微服務軟體研發和交付的各個環節，從概念到發布。組織內不再有獨立的運維團隊和職能細分，只有負責基礎設施產品 (IaaS/PaaS) 的平台團隊，提供自動化和自助式平台 UI Portal 或 API，支持各個產品團隊持續交付微服務。

從下圖我們可以看出，現代跨職能微服務組織相當於將傳統嚴格職能式組織旋轉了 90 度。DevOps 運動和微服務架構本質上是一種組織架構的重組 (Re-Org)，而不是單純的技術問題。

傳統項目型組織 vs 現代產品平台型組織

在 ThoughtWorks 推薦的 IT 領導力暢銷書《精益企業：高效能組織如何規模化創新》[附錄 4] 一書中，作者指出傳統嚴格職能和項目型組織的弊端，同時提議學習高效能組織轉型為現代產品平台型組織。

下圖是傳統嚴格職能和項目型組織，典型的職能劃分為業務方，研發團隊和運維團隊。

該組織模式的弊端包括：

各個職能團隊間易產生穀倉困局

業務方和研發團隊如缺乏信任易產生

影子 IT 和穀倉式重複系統建設

業務驅動和技術驅動的陷阱

純項目驅動易造成：

研發人員沒有業務領域知識積累，團隊穩定性差

研發和運維只顧接項目和做項目，以做項目多產出多為 KPI，既缺乏項目業務價值的關注，也沒有產品化思路和沉澱，長期造成技術體系散亂，系統耦合歷史負擔重，系統穩定性差，交付效率低下

研發和運維的目標不一致造成天然緊張關係（求快求多 vs 求穩）

下圖是現代產品平台型組織，為大部分高效能組織所採用，總體思路不複雜：

業務和產品研發閉環，圍繞微服務產品組織跨職能交付團隊

平台團隊和運維圍繞 IaaS/PaaS 基礎設施產品開展研發和運維工作，為內部客戶提供標準化平台服務

業務產品團隊通過標準 IaaS/PaaS 平台，以自助方式持續交付價值到客戶手中

該組織模式的優點包括:

圍繞核心業務和技術產品組織團隊，團隊內形成閉環，打破穀倉壁壘

以微服務方式組織團隊，各團隊可以獨立開發，測試、發布和迭代各自的微服務，互不干擾，溝通協調成本小。微服務架構是一種演進式架構，利於組織業務的不斷迭代演進。

核心業務領域服務和技術基礎設施 (IaaS/PaaS) 能夠形成標準化體系化的產品，沉澱為組織中台資產，便於組織重用、集成和規模化創新。

全部業務、研發和運維圍繞產品開展工作，統一目標，大家都是產品驅動，分別服務於內外不同客戶，避免技術驅動 vs 業務驅動的陷阱，避免研發和運維的緊張關係。

研發人員容易形成業務領域知識積累，成為領域專家，更關注業務價值，積极參与組織業務方向的制定，保持組織人才的穩定性。

四、組織案例

Netflix 的 BusDevOps 組織架構

Netflix 是一家技術強大的互聯網公司，但是它卻是沒有技術 CTO 職位的，產品團隊和技術團隊 (包括 UI 前端工程團隊、Discovery 搜索工程團隊和 Platform 平台團隊等) 全部彙報首席產品 CPO，產品驅動是該公司的核心文化要素之一，Netflix 稱其為 BusDevOps 組織架構 [附錄 6]。

Netflix 的雲平台工程團隊主要承擔基礎服務 PaaS 平台的建設和運維，對外統一向各個業務線輸出標準化的平台服務，賦能整個組織開展基於 DevOps 模式的微服務持續交付和創新。該團隊和傳統運維團隊不同，它是架構、框架中間件、雲平台、持續交付，可靠性和性能工程，基礎領域服務和大數據服務等的一個混合閉環團隊。

PaaS 是雲平台工程團隊的核心產品輸出。它是在 AWS IaaS 基礎之上的再次抽象封裝，向上支撐 Netflix 的應用服務。PaaS 平台是 Netflix 基礎技術服務能力的沉澱，核心組件大都產品化並且開源，稱為 NetflixOSS，詳見 [附錄 10]。

阿里巴巴中台戰略

2015 年底，阿里巴巴集團宣布啟動 2018 年中台戰略 [附錄 11]，構建符合 DT 時代的更靈活創新的「大中台、小前台」組織機制和業務機制：作為前台的一線業務會更敏捷，更快速適應瞬息萬變的市場；中台將集合整個集團的運營數據能力、產品技術能力，對各前台業務形成強力支撐。

阿里巴巴的「大中台、小前台」戰略架構共分四個抽象層次，從下至上依次為：

第一層（最底層）是基礎設施服務 IaaS(Infrastructure as a Service) 層，負責計算、網路、存儲、監控、發布、機房和數據中心等基礎設施。

第二層是技術平台服務 PaaS(Technical Platform as a Service) 層，負責中間件、大數據基礎服務和研發工具鏈等。第一 + 第二層在阿里體系中統稱為技術中台。

第三層是共享服務層，是阿里多年研發運營沉澱下來的核心商業能力模塊（包括用戶，商品，店鋪，營銷等等），被抽象和封裝成公共服務 API，供上層調用和集成，阿里把該層也稱為業務中台。

第四層（最上層）是前台業務層，按照不同業務線（陶寶、天貓、聚划算等）劃分，再根據不同的用戶體驗（PC，無線，第三方接入）構建不同的表示層。

總體上，阿里的「大中台、小前台」體現了：

核心業務領域和技術平台沉澱為中台服務化產品

圍繞中台產品構建基於微服務的跨職能交付團隊

強化中台產品建設支撐前端業務快速迭代演進和規模化創新，中台好比是培育和孵化業務創新生態的土壤，土壤越肥沃厚實，則其上的業務生態越繁榮。

五、更大視角

上面談了很多組織架構問題和相應的調整策略，最終的目標是通過組織敏捷達成業務敏捷，快速響應瞬息萬變的市場需求，組織敏捷同時有賴於：

架構靈活

一方面，根據康威法則，分散式模塊化的系統架構才能支持鬆散耦合高度靈活的組織架構；

另一方面，模塊化的系統架構才能支持將各種原子業務能力靈活組合出形態各異的業務模式，拓展業務邊界和可能性。

技術領先：靈活的架構依賴於領先的技術能力，PaaS 雲平台，持續交付流水線，自動化和監控測量等基礎技術能力是微服務架構的先決條件。

流程保障：研髮型組織的交付能力取決於價值流 (Value Stream) 在組織內到客戶手中的流速，價值流的速度取決於企業和客戶之間，組織團隊間，流程上和系統內各個環節的閉環反饋和持續改進。流速越快，交付能力越強，客戶響應就越及時，體驗就越好， 相應的客戶給與企業的回報就更多。良性健康的循環能夠推進企業業務持續不斷的演進。價值流可視化工具非常有用，可以幫助組織定位瓶頸，加快價值流速度，可參考 [附錄 5]。

人才和文化：不管是組織流程，還是技術架構，如果脫離人才密度就是空中樓閣。良好的企業文化能吸引和聚集優秀人才，人才和文化是企業基業常青的根基。

六、結論

根據 DevOps2016 報告，高效能組織和低效組織的生產率有數量級上差異，目前大多數技術組織仍然深陷各種困局中。

Netflix 和阿里巴巴等高效能組織的一線實踐表明，DevOps 和微服務架構是技術組織突破困局和轉型升級的最佳實踐。DevOps 和微服務轉型本質上是一種組織架構重組 (Re-Org)：將技術組織旋轉 90 度，從半職能半矩陣式組織轉型到面向市場的跨職能混搭協作式組織，組織圍繞微服務產品構建團隊和開展研發運營。組織內部團隊達成閉環，組織和市場之間達成閉環，更快更靈活地響應市場需求。

組織架構，流程，人才密度和文化等非技術因素對企業 DevOps 和微服務架構轉型的成敗至關重要。

不能將產品和技術簡單割裂，在產品導向的組織內，沒有技術驅動還是業務驅動一說，也沒有項目驅動一說，只有產品和客戶 (外部和內部) 驅動。互聯網發展到今天，社會、產業、產品、技術早就密不可分，任何創新基本都是一體化推進的，「業務制定需求、技術團隊負責做出來」的甲方乙方模型底下是落後的觀念、殘缺的認知和狹隘的本位主義思想，能否擊敗這些挑戰將會成為互聯網公司的分水嶺。

注意，

本文是作者個人學習思考總結，不代表任何官方意見。

本文的觀點假設適用於技術團隊規模超過百人以上，日流量過五千萬的成長型或成熟型技術組織。對於團隊規模小於百人的初創公司來說，謀活才是第一要務，組織結構優化並不著急，但本文思路仍可借鑒。

大新聞倒計時，5天！

七、附錄

1、2016 年 DevOps 發展報告

http://www.yunweipai.com/archives/10863.html

2、The Three Principles Underpinning DevOps

https://itrevolution.com/the-three-ways-principles-underpinning-devops/

3、Adopting Microservices at Netflix: Lessons for Team and Process Design

https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/

4、精益企業：高效能組織如何規模化創性

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B01AS1ORWM

5、CapitalOne DevOps Dashboard

https://github.com/capitalone/Hygieia

6、Netflix Global Cloud Architecture

https://www.slideshare.net/adrianco/netflix-global-cloud

7、企業 IT 架構轉型之道 (阿里巴巴中台戰略思想與架構實戰)

https://www.amazon.cn/%E4%BC%81%E4%B8%9AIT%E6%9E%B6%E6%9E%84%E8%BD%AC%E5%9E%8B%E4%B9%8B%E9%81%93-%E9%92%9F%E5%8D%8E/dp/B0725GPXWQ

8、康威法則

https://en.wikipedia.org/wiki/Conway%27s_law

9、A Bad System Will Beat a Good Person Every Time

https://blog.deming.org/2015/02/a-bad-system-will-beat-a-good-person-every-time/

10、Netflix 開源軟體中心

https://netflix.github.io/

11、阿里巴巴全面啟動中台戰略

https://www.huxiu.com/article/133482/1.html

12、企業的組織架構是如何影響技術架構的

http://www.infoq.com/cn/articles/organization-arch-influence-technology-arch

13、鳳凰項目：一個 IT 運維的傳奇故事

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B016VW1I6U

作者介紹

楊波，拍拍貸基礎框架研發總監。具有超過 10 年的互聯網分散式系統研發和架構經驗，曾先後就職於：eBay 中國研發中心（eBay CDC），任資深研發工程師，參與億貝開放 API 平台研發，攜程旅遊網（Ctrip），任技術研發總監，主導攜程大規模 SOA 體系建設，唯品會（VIPShop），任資深雲平台架構師，負責容器 PaaS 平台的調研和架構。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 InfoQ 的精彩文章: