當技術為組織所累時怎麼辦?將你的組織架構旋轉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] 一書中，作者指出傳統嚴格職能和項目型組織的弊端，同時提議學習高效能組織轉型為現代產品平臺型組織。

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

該組織模式的弊端包括：

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

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

• 平臺團隊和運維圍繞 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 和微服務架構轉型的成敗至關重要。

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

注意，

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 平臺的調研和架構。