企業(yè)IT架構團隊組建方案

1、 企業(yè)IT架構團隊組建方案關于架構可以談的東西太多，本文聚焦在組織架構維度，基本也算是筆者在當前公司里的最佳實踐（別抬杠，對您很可能不是最佳），另外部分內容參考了架構即未來一書。大家知道有三種基本的組織架構類型：職能型、矩陣型、敏捷型。而筆者的公司是敏捷型組織，對于其他兩種組織類型的架構團隊的實踐會有一些不同，本文不會做任何橫向對比，請自行找尋異同點。架構團隊的職責定位架構團隊在IT組織里到底處于什么位置，應該行使哪些職能。架構團隊的處世之道架構團隊不能超然，需要與各團隊深度合作。那么哪些基本原則需要遵守？架構評審委員會ARC這是一個很強大，一個不慎也可能走偏被唾棄的權力組織。架構團隊的職責定

2、位開篇說一下架構團隊的定位，亦或者說職責范圍。注意：下圖的職能很多可以做歸并，只當參考。非本文的論點。筆者關于架構團隊的職責定位明確為以下幾個方面。擴展性預期確保系統(tǒng)的架構和設計可以隨著業(yè)務的發(fā)展而擴展，需要在業(yè)務需要發(fā)生之前就想好，遠在業(yè)務部門的預測超過平臺的容量之前，就已經(jīng)對如何擴展系統(tǒng)深思熟慮了。 軟件的整個生命周期中，開發(fā)交付其實只是一小部分，后期的需求變更、維護升級、重構優(yōu)化才是主旋律。那么多考慮軟件的擴展性和未來預期是很有必要的，作為架構師至少看得到半年后的規(guī)模擴展吧？標準規(guī)范負責各項標準、規(guī)范、流程的設定和推行。這是架構團隊的一個重要職能，也是最容易被忽視的。技術手段并不是所有的

3、問題的最佳解決方案，很多場景通過推行標準規(guī)范就可以達到不錯的預期效果。比如編碼規(guī)范，可以通過投入大量人力來開發(fā)IDE/代碼庫的插件進行代碼規(guī)范的自動檢查，再需要不斷的測試來驗證這個插件的可靠性。通過編程考試或者平時的review來強化這一規(guī)范的落地，再加上編程規(guī)范的不斷宣導可以達到至少八成的效果，何樂而不為，最后那兩成效果就放到公司真到一定的級別了考慮技術實吧。再比如架構組研發(fā)了統(tǒng)一的基礎日志組件，可以規(guī)范日志格式、掩碼敏感信息、自動截取/壓縮超長日志報文等功能，這種組件就應該作為標準全員推廣。拆解抽象在參與業(yè)務迭代的過程中，能夠抽絲剝繭(拆解)，發(fā)現(xiàn)需求、編碼、測試、發(fā)布等環(huán)節(jié)中的痛點、共性

4、點或未來瓶頸點等進行抽象、實現(xiàn)并最終推廣全員。在代碼層面也適用，拆解交織繁雜的代碼邏輯，抽象出基礎公共模塊。都是架構團隊的基本技能。舉例來說，架構師經(jīng)常會參加各種各樣的評審，對那些常見的review comments，五花八門的自造輪子，一旦發(fā)現(xiàn)就要有這種敏感度需要制定標準規(guī)范或者研發(fā)統(tǒng)一的組件了。技術寬度架構師需要足夠的技術寬度，從軟件到硬件，從語言到操作系統(tǒng)，從編碼到測試，從運維到安全，從擁抱開源到自造輪子都要有所涉獵。有個比喻，說架構師需要具備某種上帝視角，來俯視軟件產(chǎn)品的誕生、成長、重構整個生命過程。而且架構師要有空杯心態(tài)，若學習的技術越多，就覺得自己的水平越高，那基本不會是一個合格的

5、架構師；實際應該是越學習覺得自己不懂的越多。另外，特別要有面對疑難雜癥的自信和能力，為業(yè)務團隊提供強力的技術輸出。因為疑難雜癥的最后一關就只有架構團隊。協(xié)調領導架構團隊絕對不是偏安一角寫寫基礎組件，既然要制定標準，推行規(guī)范，那就必須與其他團隊進行協(xié)作，需要征得他們的合作態(tài)度，才能順暢的推行，這個靠架構團隊在技術和業(yè)務上的影響力來驅動協(xié)調基本可以辦到。但在某些情況下，需要一些強制的手段，比如設計文檔的強制評審，那就必須賦權給架構團隊一定的權力，或者在一些矩陣型組織里架構師就是擁有技術的絕對權威，這個就是領導力。深入業(yè)務技術的存在就是為業(yè)務服務的，脫離業(yè)務的架構都是耍流氓，99%的情況下這句話都沒

6、毛病。有些技術人有嚴重的重技術輕業(yè)務思想，這種人除非真的是鉆研技術的一把好手，可能不善言談不善溝通（筆者本人是可以接受的），但是架構團隊里這種人不能多。后文我們會詳細討論下架構團隊和業(yè)務團隊的協(xié)作問題。創(chuàng)新突破架構團隊在IT內部必須是第一生產(chǎn)力，不管是單兵作戰(zhàn)還是團戰(zhàn)能力。除了過硬的基本功外，不斷的學習和尋求技術上的突破，是貫穿架構團隊始終的一個Object。前人已經(jīng)累計了很多經(jīng)典優(yōu)秀的平臺、框架或思想作為傳承，我們可以繼承但絕不能守舊。在學術研究中，“創(chuàng)新”一詞用來表示團隊有增加值的產(chǎn)出。而有些創(chuàng)新調研項目很多時候并不會有實際的產(chǎn)出，甚至更糟糕些，會產(chǎn)生許多沉沒成本，但這都不是阻礙創(chuàng)新的借口

7、。創(chuàng)新是架構團隊延續(xù)生命力的最佳營養(yǎng)品和必要條件?？梢韵胂鬀]有創(chuàng)新突破，架構團隊完全可以就地解散。架構團隊的處世之道架構即未來架構真經(jīng)兩本經(jīng)典架構書里都對架構的原則展開了很多，但都是偏向技術層面的。這里我要另辟蹊徑，說的不只是架構本身的原則，還有架構團隊如何玩得轉的原則，跟上文架構團隊的定位是戚戚相關的：可抽象的有基礎組件面相的實現(xiàn)盡量由架構統(tǒng)一實現(xiàn)，然后推動各系統(tǒng)使用通用的基礎框架，而不是每個系統(tǒng)寫。比如加解密，比如HTTP客戶端，并不是所有人對加密的填充、編碼、提供者都有清晰的認識，也并不是所有人對HTTP客戶端里的超時時間、DEFAULT_MAX_PER_ROUTE、SSL配置等都了解，

8、專業(yè)的事情交給相對更加專業(yè)的人去實現(xiàn)。架構即未來里提到一條“要使用成熟的技術”，個人延伸一下：不僅如此還要使用盡量統(tǒng)一的技術，盡量統(tǒng)一的代碼層級結構（起碼有一些約定俗成的層級）。有人用Gson, fastjson，jackson的比比皆是，hibernate/mybatis也是各有所好。都是成熟的技術，但是不統(tǒng)一，導致了不管是矩陣式還是敏捷式團隊，同一個人維護不同系統(tǒng)時，必然會有一些不適應，需要思維的跳躍，無形的增加很多非必要成本；再者不同技術的引入可能會增加更多的BUG或管控風險和排障的難度。常見的代碼層級結構 controller-business-service-dao，在一些人的項目里

9、 business變成了handler, service變成了proxy，怎么都會讓人無所適從吧？微服務體系內的單體系統(tǒng)必須做好自我保護，這是架構團隊理應對IT產(chǎn)品做出的承諾。服務提供方根據(jù)需求說明設計并承諾了一個服務接口定義，如果調用方只管調用服務方只管實現(xiàn)，一個不慎就會把接口設計成一顆雷。比如會員系統(tǒng)提供用戶基本信息的查詢接口，這個接口提供的用戶信息“基本”的邊界在哪里，單表查詢也就罷了，如果需要多表連接查詢呢？有些人喜歡把這個接口做的大而全，很靈活，比如在最基礎的用戶信息之上，會附加一些其他字段如QQ號，工作單位，年收入等等算不上基本信息的信息，只要調用方多傳入一些參數(shù)即可。確實感覺靈活

10、了，但為此服務方不得不做各種的入?yún)⑴袛嗪蚐QL拼接，最差的情況可能需要關聯(lián)用戶的所有相關表，性能差到冰點不用說，對系統(tǒng)本身的吞吐量和并發(fā)能力都會有特別大的影響。這就是系統(tǒng)沒有自我保護好。因為并不是說系統(tǒng)有什么BUG， 但是因為這個靈活度引入了極大的性能隱患。再比如用戶列表的查詢，服務使用方傳入?yún)?shù)作為WHERE條件進行過濾，如果使用方什么都不傳，這個查詢接口基本等同于全表查詢的脫庫了。這時候必掛無疑，那么是不是應該加上分頁，或者最大結果集的限定條件進行自我保護呢？架構團隊的任何框架、組件級別的需求，都應該做好充分調研，不能閉門造車自己臆想需求。技術人很少能做到喬幫主似的，對方不知道自己想要什么

11、由我來告訴你應該用什么；再者如果臆想的實現(xiàn)最終發(fā)現(xiàn)并不適用又耗費了大量成本，或多或少總會被別的團隊看輕吧，身為架構師如何能忍？而且把需求調研溝通清楚，未來推廣也會得到大家的支持，很簡單，因為需求是大家一起提出來的。任何的標準規(guī)范的推行、框架組件的立項、實現(xiàn)和發(fā)布需要獲得高層的充分授權，也需要與重要干系人（比如團隊或職能部門負責人）提前溝通好，減少推動阻力，獲得推行計劃的承諾。比如為了線上系統(tǒng)的監(jiān)控和排障考慮，需要有健康檢查、規(guī)范的日志格式等，這些業(yè)務需求之外的任務勢必會增加業(yè)務團隊的負擔，如果沒有從上至下的強制性推動，很難有實際進展。架構團隊萬勿把自身置為其他團隊的對立面。在迭代周期內的重要環(huán)

12、節(jié)都需要有架構團隊(或架構評審委員會,后文會詳說)的深度參與，包括需求調研，接口/數(shù)據(jù)庫設計評審，代碼評審，上線評審等。這個對于創(chuàng)業(yè)公司起步階段特別有益，因為在規(guī)范和標準沒有在IT內部形成一種文化驅動的高度，同一個事情被不同的人做出來完全是千人千面，那對于一個組織來說，這種不可控是很危險的。特別注意，這些參與絕對不能以俯視批判挑毛病的角度展開，而應該以合作共贏建議的方式展開。當然如果是無法妥協(xié)的雙方起沖突的問題必須通過授權來強制修正。架構及未來把監(jiān)控設計放在15條原則的第4條，它也是筆者推崇的一個重要原則。監(jiān)控可以把我們整個系統(tǒng)的健康度清晰的展示出來，兩眼一抹黑只是另一種形式的掩耳盜鈴。監(jiān)控的

13、顆粒度細化到什么程度需要視團隊成熟度有所不同，不在本文討論范圍。重要的是，監(jiān)控設計應該在系統(tǒng)的初期概要設計期間作為非功能性需求就考慮進去。再做個提醒，監(jiān)控可以視作運維工作的一部分，所以在前期做架構設計的時候，一些運維工作也應該記錄Involve進來。文件傳輸?shù)降走x擇FTP還是接口傳輸，有沒有考慮運維帶寬、斷點續(xù)傳、CDN等問題呢？盡量通過工程化來替代人工。工程化就是Engineering，軟件工程化是個比較抽象的概念，就是把軟件按照工程的方式進行開發(fā)維護。這里我們說的工程化可以簡單理解成工具化，自動化的動手文化。當然這里的“動手”不是打架，而是敲代碼，Just show me the code

14、。我們的自動化運維、實時監(jiān)控告警、自動化發(fā)布、智能排障，都是工程化手段來解放人力。這也是驅使團隊不斷進步的一種方式，不能陷在一些重復勞動的舒適區(qū)里，要不斷的想辦法改進工作效率和質量。架構團隊出品的任何產(chǎn)品、流程必須建立最嚴格的標準，比如代碼質量、性能指標、監(jiān)控指標、高可用性、可擴展性等。在一個大的組織架構里建立信任是個很慢的過程，但是失去信任卻可能是瞬間的。“架構出品，必屬精品”應該是架構團隊的一塊金字招牌，必須保護好。Besides, 架構團隊要有比較優(yōu)秀的宣傳能力，能夠把自己的產(chǎn)品包裝成一個高附加值的優(yōu)秀作品，好像你不用就會懊惱一輩子似的，當然這一切都是必須是真實的不能盲目夸大。因為筆者是

15、實實在在看過不少架構師撰寫的產(chǎn)品發(fā)布郵件，寫的不痛不癢，平平淡淡，完全激不起想要試用一下的沖動，還何談推廣。線上系統(tǒng)特別注意驚群效應的影響。比如緩存失效后，如何解決驚群效應帶來的數(shù)據(jù)庫或者微服務化鏈路尾端服務的壓力驟增的問題。這個是技術問題。比如秒殺場景下會有平時百倍千倍萬倍的流量打進來，服務器資源會被瞬間消耗殆盡導致崩潰和癱瘓，這就不僅僅是技術問題了，還有與前線業(yè)務方協(xié)調溝通的問題，這種活動必須提前通知到IT。來自維基百科：Thundering herd problem驚群問題是計算機科學中，當許多進程等待一個事件，事件發(fā)生后所有這些進程被喚醒，而只有一個進程能獲得CPU執(zhí)行權，其他進程又得

16、被阻塞，這造成了嚴重的系統(tǒng)上下文切換代價。C10K/C10M問題都與這個相關。還有兩個類似的術語一并介紹下：“Slashdot effect點杠效應”這個詞指的是當著名新聞網(wǎng)站Slashdot在一篇有趣的文章里報道了一個網(wǎng)站后許多人紛至沓來把它幾乎擠爆的現(xiàn)象。后來被列入其他著名網(wǎng)站后所發(fā)生的類似現(xiàn)象也用這個詞來稱呼了。這個詞和Flash crowd這個更一般性、更合適的詞對應?！癋lash crowd突發(fā)訪問擁堵”這個詞是1973年Larry Niven在他的短篇科幻小說Flash Crowd中生造出來的。小說預言了廉價的瞬移技術會使得一大群人都會傳送到有趣的新聞故事發(fā)生的地方從而導致?lián)矶隆?

17、0年后，這個詞在互聯(lián)網(wǎng)上被廣泛用于指當網(wǎng)站有了能吸引許多人的東西之后其服務器系統(tǒng)資源使用量成指數(shù)增長。在此之前，Alfred Bester在他的小說The Stars My Destination中也預計到了這種效應。架構團隊 versus 業(yè)務團隊單獨拎出來這兩個團隊的相處之道并不是說這兩個團隊有什么不得了的沖突（相較于開發(fā)vs測試，開發(fā)vs運維，測試vs運維），只是只要有協(xié)作就會出現(xiàn)問題，但是這個沖突并不難解決。其實上文也斷斷續(xù)續(xù)提到一些原則，但終極方案無外乎兩個詞：尊重和信任。架構要得到尊重就要在技術上保持先進性，且必須對業(yè)務有一定的深入度；業(yè)務要得到尊重那就除了要在業(yè)務上有深刻理解，在

18、與技術的結合上也必須有自己的思考。而事關信任，雙方只要在自己發(fā)布的產(chǎn)品上傾注足夠的專注度，展示了自己的態(tài)度，最后又保證了質量和口碑，就會逐步建立起信任關系。架構評審委員會ARC定義七拼八湊好不容易整理了一個個人還算滿意的定義：架構評審委員會ArchitectReviewCommittee作為IT的一個治理監(jiān)管機構，有權力確保IT運轉在整個架構生態(tài)內保持一致，提高IT的產(chǎn)品質量，并最終與公司的目標、戰(zhàn)略達成一致。架構即未來一書中架構評審委員會的縮寫是AR B(oard)，筆者選擇了ARC純粹是為了好記好發(fā)音。其實ARB才是業(yè)界主流說法.那為什么要有ARC？是否必要呢？那是必然的。上圖中歸納的5大

19、塊：技術、流程、標準、質量和創(chuàng)新都在ARC的轄內，且ARC有絕對的話語權提供決策結果，另外ARC也是捏合架構團隊（落地）、PMO（項目管理辦公室）和業(yè)務團隊的關鍵機構。不能再搞笑的是筆者竟然先看到了微軟2012年的一篇題為的文章.WTF.傳送門:/nickmalik/2012/04/17/should-we-kill-the-architecture-review-board/我簡單給大家歸納一下文中表達的意思：按照COBIT標準IT的治理體系應該有三個委員會：架構Arch委員會、策略Strategy委員會和指導Steering委員會 ，而架構委員會只對項目工程有話語權，指導委員會卻對IT投資

20、、預算和交付等有話語權，一句話就是管錢袋子的定規(guī)則，架構委員會干不過指導委員會。既然架構委員會說了不算那就不要了，成立一個CIO牽頭的說了算的IT治理委員會，來完成滿足COBIT標準的事情。標題說的那么嚇人說Kill掉，其實也就是因為微軟里的ARB說了不算，對于決策權這個在筆者的定義里已經(jīng)標明了。咱們中小型公司沒有也不需要微軟那么大的標準體系，當然不關心那么多道道，三者合一就叫ARC來行使所有IT治理框架需要的所有職能。創(chuàng)業(yè)公司如果有如下困擾，并開始越來越明顯的影響到IT正常的運作，那么貴公司應該考慮成立ARC：軟件產(chǎn)品的質量不可控，時常發(fā)生缺陷Escapse到線上生產(chǎn)環(huán)境的事件；職能團隊、業(yè)

21、務團隊、項目團隊之間各自為戰(zhàn)，沒有統(tǒng)一的規(guī)范，代碼、接口、數(shù)據(jù)庫千變萬化，比如那些三無項目：無注釋無文檔無單元測試；有各種各樣的阻力或者痼疾導致無法推動持續(xù)交付/持續(xù)部署的進行；研發(fā)團隊與測試團隊之間脫節(jié)，比如研發(fā)不自測就提交測試，測試團隊在需求階段未被拉入，導致測試案例缺失等；IT產(chǎn)品整體在架構、治理方面沒有人或者只有CTO一人負責，導致IT團隊對產(chǎn)品的遠期路線線缺乏足夠的認識，僅僅滿足于實現(xiàn)業(yè)務功能而已；公司已經(jīng)出具規(guī)模了，但非功能性需求還從來沒有被正式提出來過，性能、安全等。職能范圍提高軟件產(chǎn)品的質量規(guī)劃，設計和實施IT基礎設施和應用程序健壯的、可擴展的、可靠安全的架構定義架構設計的標準，政策和總體原則建立和推廣優(yōu)秀架構設計的最佳實踐創(chuàng)建架構的路線圖：持續(xù)交付、灰度發(fā)布、服務治理、智能監(jiān)控等等負責軟件產(chǎn)品在各個過程環(huán)節(jié)的評審，包括但不限于可行性、需求、接口、數(shù)據(jù)庫、生產(chǎn)發(fā)布等的評審保持對新技術、新框架、新思想的敏感度和足夠的深入度，方能從容應對未來可能的升級必須保證擁有或者領導權或者充分的授權驅動IT產(chǎn)品的創(chuàng)新和升級，補齊短板，但是要做好與常規(guī)任務的權衡工作原則嚴格堅持統(tǒng)一的評審標準，堅決不能存在雙標情況，否則會降低ARC的權威性；確保ARC過程得到足夠的尊重，且ARC一旦產(chǎn)生結論則被視為