漫談 “架構團隊” 之組織架構

  按語：曲健老師，82 年生人，2004 年參加工作。曾任米麼金服首席架構師、CTO。曾任職上海社保、infosys、招商銀行。右導和那些專業編輯不同之處在於往往於朋友圈或者某個羣三言兩語得識知己，或請賜稿一二。得之，我幸亦是讀者之幸。沒有閱讀量、訂閱量 KPI 考覈，不忘初心方得始終。

架構團隊的職責定位

架構團隊在 IT 組織裏到底處於什麼位置，應該行使哪些職能。

架構團隊的處世之道

架構團隊不能超然，需要與各團隊深度合作。那麼哪些基本原則需要遵守？

架構評審委員會 ARC

這是一個很強大，一個不慎也可能走偏被唾棄的權力組織。

架構團隊的職責定位

圖片

圖片

筆者關於架構團隊的職責定位明確爲以下幾個方面。

擴展性預期

確保系統的架構和設計可以隨着業務的發展而擴展，需要在 "業務需要" 發生之前就想好，遠在業務部門的預測超過平臺的容量之前，就已經對如何擴展系統深思熟慮了。軟件的整個生命週期中，開發交付其實只是一小部分，後期的需求變更、維護升級、重構優化纔是主旋律。那麼多考慮軟件的擴展性和未來預期是很有必要的，作爲架構師至少看得到半年後的規模擴展吧？

標準規範

負責各項標準、規範、流程的設定和推行。這是架構團隊的一個重要職能，也是最容易被忽視的。技術手段並不是所有的問題的最佳解決方案，很多場景通過推行標準規範就可以達到不錯的預期效果。

比如編碼規範，可以通過投入大量人力來開發 IDE / 代碼庫的插件進行代碼規範的自動檢查，再需要不斷的測試來驗證這個插件的可靠性。通過編程考試或者平時的 review 來強化這一規範的落地，再加上編程規範的不斷宣導可以達到至少八成的效果，何樂而不爲，最後那兩成效果就放到公司真到一定的級別了考慮技術實吧。再比如架構組研發了統一的基礎日誌組件，可以規範日誌格式、掩碼敏感信息、自動截取 / 壓縮超長日誌報文等功能，這種組件就應該作爲標準全員推廣。

拆解抽象

在參與業務迭代的過程中，能夠抽絲剝繭 (拆解)，發現需求、編碼、測試、發佈等環節中的痛點、共性點或未來瓶頸點等進行抽象、實現並最終推廣全員。在代碼層面也適用，拆解交織繁雜的代碼邏輯，抽象出基礎公共模塊。都是架構團隊的基本技能。

舉例來說，架構師經常會參加各種各樣的評審，對那些常見的 review comments，五花八門的自造輪子，一旦發現就要有這種敏感度需要制定標準規範或者研發統一的組件了。

技術寬度

架構師需要足夠的技術寬度，從軟件到硬件，從語言到操作系統，從編碼到測試，從運維到安全，從擁抱開源到自造輪子都要有所涉獵。有個比喻，說架構師需要具備某種上帝視角，來俯視軟件產品的誕生、成長、重構整個生命過程。而且架構師要有空杯心態，若學習的技術越多，就覺得自己的水平越高，那基本不會是一個合格的架構師；實際應該是越學習覺得自己不懂的越多。

另外，特別要有面對疑難雜症的自信和能力，爲業務團隊提供強力的技術輸出。因爲疑難雜症的最後一關就只有架構團隊。

協調領導

架構團隊絕對不是偏安一角寫寫基礎組件，既然要制定標準，推行規範，那就必須與其他團隊進行協作，需要徵得他們的合作態度，才能順暢的推行，這個靠架構團隊在技術和業務上的影響力來驅動協調基本可以辦到。但在某些情況下，需要一些強制的手段，比如設計文檔的強制評審，那就必須賦權給架構團隊一定的權力，或者在一些矩陣型組織裏架構師就是擁有技術的絕對權威，這個就是領導力。

深入業務

技術的存在就是爲業務服務的，脫離業務的架構都是耍流氓，99% 的情況下這句話都沒毛病。有些技術人有嚴重的重技術輕業務思想，這種人除非真的是鑽研技術的一把好手，可能不善言談不善溝通（筆者本人是可以接受的），但是架構團隊裏這種人不能多。後文我們會詳細討論下架構團隊和業務團隊的協作問題。

創新突破

架構團隊在 IT 內部必須是第一生產力，不管是單兵作戰還是團戰能力。除了過硬的基本功外，不斷的學習和尋求技術上的突破，是貫穿架構團隊始終的一個 Object。前人已經累計了很多經典優秀的平臺、框架或思想作爲傳承，我們可以繼承但絕不能守舊。

在學術研究中，“創新” 一詞用來表示團隊有增加值的產出。而有些創新調研項目很多時候並不會有實際的產出，甚至更糟糕些，會產生許多沉沒成本，但這都不是阻礙創新的藉口。創新是架構團隊延續生命力的最佳營養品和必要條件。可以想象沒有創新突破，架構團隊完全可以就地解散。

架構團隊的處世之道

《架構即未來》《架構真經》兩本經典架構書裏都對架構的原則展開了很多，但都是偏向技術層面的。這裏我要另闢蹊徑，說的不只是架構本身的原則，還有架構團隊如何玩得轉的原則，跟上文架構團隊的定位是慼慼相關的：

1. 可抽象的有基礎組件面相的實現儘量由架構統一實現，然後推動各系統使用通用的基礎框架，而不是每個系統寫。比如加解密，比如 HTTP 客戶端，並不是所有人對加密的填充、編碼、提供者都有清晰的認識，也並不是所有人對 HTTP 客戶端裏的超時時間、DEFAULT_MAX_PER_ROUTE、SSL 配置等都瞭解，專業的事情交給相對更加專業的人去實現。

2. 《架構即未來》裏提到一條 “要使用成熟的技術”，個人延伸一下：不僅如此還要使用盡量統一的技術，儘量統一的代碼層級結構（起碼有一些約定俗成的層級）。有人用 Gson, fastjson，jackson 的比比皆是，hibernate/mybatis 也是各有所好。都是成熟的技術，但是不統一，導致了不管是矩陣式還是敏捷式團隊，同一個人維護不同系統時，必然會有一些不適應，需要思維的跳躍，無形的增加很多非必要成本；再者不同技術的引入可能會增加更多的 BUG 或管控風險和排障的難度。

   常見的代碼層級結構 controller->business->service->dao，在一些人的項目裏 business 變成了 handler, service 變成了 proxy，怎麼都會讓人無所適從吧？

3. 微服務體系內的單體系統必須做好自我保護，這是架構團隊理應對 IT 產品做出的承諾。服務提供方根據需求說明設計並承諾了一個服務接口定義，如果調用方只管調用服務方只管實現，一個不慎就會把接口設計成一顆雷。

   比如會員系統提供用戶基本信息的查詢接口，這個接口提供的用戶信息 “基本” 的邊界在哪裏，單表查詢也就罷了，如果需要多表連接查詢呢？有些人喜歡把這個接口做的大而全，很靈活，比如在最基礎的用戶信息之上，會附加一些其他字段如 QQ 號，工作單位，年收入等等算不上基本信息的信息，只要調用方多傳入一些參數即可。確實感覺靈活了，但爲此服務方不得不做各種的入參判斷和 SQL 拼接，最差的情況可能需要關聯用戶的所有相關表，性能差到冰點不用說，對系統本身的吞吐量和併發能力都會有特別大的影響。這就是系統沒有自我保護好。因爲並不是說系統有什麼 BUG， 但是因爲這個靈活度引入了極大的性能隱患。

   再比如用戶列表的查詢，服務使用方傳入參數作爲 WHERE 條件進行過濾，如果使用方什麼都不傳，這個查詢接口基本等同於全表查詢的脫庫了。這時候必掛無疑，那麼是不是應該加上分頁，或者最大結果集的限定條件進行自我保護呢？

4. 架構團隊的任何框架、組件級別的需求，都應該做好充分調研，不能閉門造車自己臆想需求。技術人很少能做到喬幫主似的，對方不知道自己想要什麼由我來告訴你應該用什麼；再者如果臆想的實現最終發現並不適用又耗費了大量成本，或多或少總會被別的團隊看輕吧，身爲架構師如何能忍？而且把需求調研溝通清楚，未來推廣也會得到大家的支持，很簡單，因爲需求是大家一起提出來的。

5. 任何的標準規範的推行、框架組件的立項、實現和發佈需要獲得高層的充分授權，也需要與重要干係人（比如團隊或職能部門負責人）提前溝通好，減少推動阻力，獲得推行計劃的承諾。比如爲了線上系統的監控和排障考慮，需要有健康檢查、規範的日誌格式等，這些業務需求之外的任務勢必會增加業務團隊的負擔，如果沒有從上至下的強制性推動，很難有實際進展。架構團隊萬勿把自身置爲其他團隊的對立面。

6. 在迭代週期內的重要環節都需要有架構團隊 (或架構評審委員會, 後文會詳說) 的深度參與，包括需求調研，接口 / 數據庫設計評審，代碼評審，上線評審等。這個對於創業公司起步階段特別有益，因爲在規範和標準沒有在 IT 內部形成一種文化驅動的高度，同一個事情被不同的人做出來完全是千人千面，那對於一個組織來說，這種不可控是很危險的。

   特別注意，這些參與絕對不能以俯視批判挑毛病的角度展開，而應該以合作共贏建議的方式展開。當然如果是無法妥協的雙方起衝突的問題必須通過授權來強制修正。

7. 《架構及未來》把監控設計放在 15 條原則的第 4 條，它也是筆者推崇的一個重要原則。監控可以把我們整個系統的健康度清晰的展示出來，兩眼一抹黑只是另一種形式的掩耳盜鈴。監控的顆粒度細化到什麼程度需要視團隊成熟度有所不同，不在本文討論範圍。重要的是，監控設計應該在系統的初期概要設計期間作爲非功能性需求就考慮進去。

   再做個提醒，監控可以視作運維工作的一部分，所以在前期做架構設計的時候，一些運維工作也應該記錄 Involve 進來。文件傳輸到底選擇 FTP 還是接口傳輸，有沒有考慮運維帶寬、斷點續傳、CDN 等問題呢？

8. 儘量通過工程化來替代人工。工程化就是 Engineering，軟件工程化是個比較抽象的概念，就是把軟件按照工程的方式進行開發維護。這裏我們說的工程化可以簡單理解成工具化，自動化的動手文化。當然這裏的 “動手” 不是打架，而是敲代碼，Just show me the code。我們的自動化運維、實時監控告警、自動化發佈、智能排障，都是工程化手段來解放人力。這也是驅使團隊不斷進步的一種方式，不能陷在一些重複勞動的舒適區裏，要不斷的想辦法改進工作效率和質量。

9. 架構團隊出品的任何產品、流程必須建立最嚴格的標準，比如代碼質量、性能指標、監控指標、高可用性、可擴展性等。在一個大的組織架構裏建立信任是個很慢的過程，但是失去信任卻可能是瞬間的。“架構出品，必屬精品” 應該是架構團隊的一塊金字招牌，必須保護好。Besides, 架構團隊要有比較優秀的宣傳能力，能夠把自己的產品包裝成一個高附加值的優秀作品，好像你不用就會懊惱一輩子似的，當然這一切都是必須是真實的不能盲目誇大。因爲筆者是實實在在看過不少架構師撰寫的產品發佈郵件，寫的不痛不癢，平平淡淡，完全激不起想要試用一下的衝動，還何談推廣。

10. 線上系統特別注意驚羣效應的影響。比如緩存失效後，如何解決驚羣效應帶來的數據庫或者微服務化鏈路尾端服務的壓力驟增的問題。這個是技術問題。比如秒殺場景下會有平時百倍千倍萬倍的流量打進來，服務器資源會被瞬間消耗殆盡導致崩潰和癱瘓，這就不僅僅是技術問題了，還有與前線業務方協調溝通的問題，這種活動必須提前通知到 IT。

圖片

來自維基百科：

Thundering herd problem 驚羣問題是計算機科學中，當許多進程等待一個事件，事件發生後所有這些進程被喚醒，而只有一個進程能獲得 CPU 執行權，其他進程又得被阻塞，這造成了嚴重的系統上下文切換代價。C10K/C10M 問題都與這個相關。

還有兩個類似的術語一併介紹下：

“Slashdot effect 點槓效應” 這個詞指的是當著名新聞網站 Slashdot 在一篇有趣的文章裏報道了一個網站後許多人紛至沓來把它幾乎擠爆的現象。後來被列入其他著名網站後所發生的類似現象也用這個詞來稱呼了。這個詞和 Flash crowd 這個更一般性、更合適的詞對應。

“Flash crowd 突發訪問擁堵” 這個詞是 1973 年 Larry Niven 在他的短篇科幻小說 Flash Crowd 中生造出來的。小說預言了廉價的瞬移技術會使得一大羣人都會傳送到有趣的新聞故事發生的地方從而導致擁堵。20 年後，這個詞在互聯網上被廣泛用於指當網站有了能吸引許多人的東西之後其服務器系統資源使用量成指數增長。在此之前，Alfred Bester 在他的小說 The Stars My Destination 中也預計到了這種效應。

架構團隊 versus 業務團隊

單獨拎出來這兩個團隊的相處之道並不是說這兩個團隊有什麼不得了的衝突（相較於開發 vs 測試，開發 vs 運維，測試 vs 運維），只是只要有協作就會出現問題，但是這個衝突並不難解決。其實上文也斷斷續續提到一些原則，但終極方案無外乎兩個詞：尊重和信任。

架構要得到尊重就要在技術上保持先進性，且必須對業務有一定的深入度；業務要得到尊重那就除了要在業務上有深刻理解，在與技術的結合上也必須有自己的思考。而事關信任，雙方只要在自己發佈的產品上傾注足夠的專注度，展示了自己的態度，最後又保證了質量和口碑，就會逐步建立起信任關係。

架構評審委員會 ARC

圖片

定義

七拼八湊好不容易整理了一個個人還算滿意的定義：架構評審委員會 Architect Review Committee 作爲 IT 的一個治理監管機構，有權力確保 IT 運轉在整個架構生態內保持一致，提高 IT 的產品質量，並最終與公司的目標、戰略達成一致。

《架構即未來》一書中架構評審委員會的縮寫是 AR B(oard)，筆者選擇了 ARC 純粹是爲了好記好發音。其實 ARB 纔是業界主流說法...

那爲什麼要有 ARC？是否必要呢？那是必然的。上圖中歸納的 5 大塊：技術、流程、標準、質量和創新都在 ARC 的轄內，且 ARC 有絕對的話語權提供決策結果，另外 ARC 也是捏合架構團隊（落地）、PMO（項目管理辦公室）和業務團隊的關鍵機構。

不能再搞笑的是筆者竟然先看到了微軟 2012 年的一篇題爲 <Should We Kill The Architecture Review Board?> 的文章...WTF...

傳送門: https://blogs.msdn.microsoft.com/nickmalik/2012/04/17/should-we-kill-the-architecture-review-board/

我簡單給大家歸納一下文中表達的意思：按照 COBIT 標準 IT 的治理體系應該有三個委員會：架構 Arch 委員會、策略 Strategy 委員會和指導 Steering 委員會 ，而架構委員會只對項目工程有話語權，指導委員會卻對 IT 投資、預算和交付等有話語權，一句話就是管錢袋子的定規則，架構委員會幹不過指導委員會。既然架構委員會說了不算那就不要了，成立一個 CIO 牽頭的說了算的 IT 治理委員會，來完成滿足 COBIT 標準的事情。標題說的那麼嚇人說 Kill 掉，其實也就是因爲微軟裏的 ARB 說了不算，對於決策權這個在筆者的定義裏已經標明瞭。

咱們中小型公司沒有也不需要微軟那麼大的標準體系，當然不關心那麼多道道，三者合一就叫 ARC 來行使所有 IT 治理框架需要的所有職能。

創業公司如果有如下困擾，並開始越來越明顯的影響到 IT 正常的運作，那麼貴公司應該考慮成立 ARC：

• 軟件產品的質量不可控，時常發生缺陷 Escapse 到線上生產環境的事件；

• 職能團隊、業務團隊、項目團隊之間各自爲戰，沒有統一的規範，代碼、接口、數據庫千變萬化，比如那些三無項目：無註釋無文檔無單元測試；

• 有各種各樣的阻力或者痼疾導致無法推動持續交付 / 持續部署的進行；

• 研發團隊與測試團隊之間脫節，比如研發不自測就提交測試，測試團隊在需求階段未被拉入，導致測試案例缺失等；

• IT 產品整體在架構、治理方面沒有人或者只有 CTO 一人負責，導致 IT 團隊對產品的遠期路線線缺乏足夠的認識，僅僅滿足於實現業務功能而已；

• 公司已經出具規模了，但非功能性需求還從來沒有被正式提出來過，性能、安全等。

職能範圍

1. 提高軟件產品的質量

2. 規劃，設計和實施 IT 基礎設施和應用程序健壯的、可擴展的、可靠安全的架構

3. 定義架構設計的標準，政策和總體原則

4. 建立和推廣優秀架構設計的最佳實踐

5. 創建架構的路線圖：持續交付、灰度發佈、服務治理、智能監控等等

6. 負責軟件產品在各個過程環節的評審，包括但不限於可行性、需求、接口、數據庫、生產發佈等的評審

7. 保持對新技術、新框架、新思想的敏感度和足夠的深入度，方能從容應對未來可能的升級

8. 必須保證擁有或者領導權或者充分的授權

9. 驅動 IT 產品的創新和升級，補齊短板，但是要做好與常規任務的權衡

工作原則

1. 嚴格堅持統一的評審標準，堅決不能存在雙標情況，否則會降低 ARC 的權威性；

2. 確保 ARC 過程得到足夠的尊重，且 ARC 一旦產生結論則被視爲最終決定。若最終評審結果得不到修正，浪費大家的時間，ARC 失去公信力，標準規範也就失去了意義。

3. 不能以任何理由，比如常見的項目週期緊就不要評審了之類的藉口，隨隨便便繞開 ARC 過程。一旦開了頭就會有其他團隊的效仿並繞開，最終 ARC 的價值就會不斷被迅速削弱。

4. ARC 組織內必須固定一部分永久性的委員，可以是有話語權有地位的領導（CTO，總監，VP），可以是專業或技術上有威望的專家（架構師，業務負責人等），這部分的委員是保證 ARC 流程是可以容易下達傳導的。其他再配置一些某些專長的候選人作爲輪換委員，作爲 ARC 過程的補充力量，畢竟 ARC 組織的人數相比整個 IT 組織是遠不夠用的。

   發生如下情況說明成員需要調整了：

   a. 時不時的發生 ARC 成員之間的意見不一致, 總有一方要被踢出去，保證內部的絕對統一；

   b. 發現成員有濫用權力、刁難、憑個人好惡等違反公司利益的方式做事，必須剔除並作爲長期關注對象，以防做出其他對公司有損害的事情；

   c. ARC 過程經常被合理挑戰，而且挑戰的結果是對的，這個人可以考慮被培養並吸納；

5. ARC 的大部分活動實際上對於每個成員來說是一種額外的工作，在保證自己日常工作的情況下還要隨時出席各種的 ARC 會議，這對 ARC 成員的日常工作規劃是個考驗，所以 ARC 過程和會議都要儘可能的準備充分和直接了當。比如代碼接口評審的代碼必須提前準備好演示 IDE 環境，數據庫評審提前準備好 PDM, 會議過程要足夠的 FOCUS，不能太發散導致會議時間過長。

6. 某些時候不得不在 ARC 的權威性和業務排期之間做選擇的時候，一定要拋給決策高層 (比如 CTO) 來做出決定，ARC 不能站出來當 "惡人"。反過來，如果 ARC 對業務團隊的資源佔用經常被抱怨，那必須考慮重新調整輕量化 ARC 的過程了。

終於寫完了，基本都是大段大段的文字，配圖都不好配，確實不如貼代碼來的舒爽，可能大家會看的比較累。我就再總結一下，其實主要就說了一下架構團隊應該如何以及如何更好的自處或他處，IT 管理者如何使用好架構團隊這把尖刀的事情。論點太多沒有再花時間找到他們的內在聯繫做個歸集，還請各位看客多擔待，擱筆。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7JLpVJAcQBhhX306IcAFrQ