【51CTO.com原創稿件】互聯網企業的并購不僅是組織結構的融合，更是產品架構和產品團隊的融合。特別是涉及不同的企業文化、技術能力甚至是不同的國家法律法規上的融合，存在更多看不到的隱形成本。

近日，由51CTO主辦的第十六期以“Tech Neo”為主題的技術沙龍在北京舉行，此次活動邀請了來自Thought Works 高級咨詢師顧宇老師。他分享了一個東南亞互聯網企業并購中的DevOps 促進并購的實施案例，即通過在 AWS上使用 Ansible和CloudFormation作為基礎設施即代碼的工具實現產品架構的遷移。

本文介紹如何通過 DevOps的基礎設施即代碼實踐，把架構以及開發/運維實踐和規則固化為配置和代碼。讓所有的團隊和成員能夠依照同樣的規則進行開發和運維；通過自動化的手段加速團隊、產品和架構的融合過程，提升整個組織的技術水平。減少組織間的溝通摩擦。

跨國互聯網公司并購案例

案例梗概：某企業收購了分布在泰國、馬來西亞、印度尼西亞、新家坡等地的幾家東南亞擁有相同業務的互聯網公司。但如何在多國家、多語言文化的情況下，進行分布式IT敏捷產品團隊的合并、步調一致的工作和實現統一的管理成為難題。

剖析組織現狀

既要保留各個國家的業務團隊，又要集中管理IT團隊，首當其沖的是剖析組織現狀。那么，做架構遷移要先了解哪些組織現狀呢？ ″

康威定律原話：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。

這句話中“constrained”的意思是強制。也就是說，當系統架構與組織架構不匹配時，系統結構會被強制轉化成與組織架構一致。要做到組織架構和基礎設施架構保持一致，就需要根據未來的組織結構設計系統架構，減少系統架構演進中的適應性浪費。

如下圖，是合并前架構的情況： 

如圖中所示，每個國家的公司運營著自己的網站。其中每一公司都有一部分是用WordPress運營的。雖然都是 Wordpress，但應用架構和使用方式上存在著諸多的差異。我們首先是要識別出這種差異。而這種差異不僅僅是技術上的，還有組織上的。 并購并不僅僅是把團隊合并到一起就能解決問題，而是要把多國、多語言、多站點，變成多國、多語言、單站點。通過一個站點來支撐多個地區的業務，這里選擇馬來西亞作為這個站點進行舉例。

那么，組織架構就會辦成如下圖所示： 

[[212063]]

當組織架構變成多國、多語言、單站點，那么所對應的就是一個IT團隊。如圖可以看到把Dev、Ops分開來表示，這樣的組織結構和DevOps有什么關系呢？這就需要了解下DevOps的兩種組織形式：

• Team Own Ops：團隊內自有的Ops，把Ops當做團隊成員，實現開發和運維合作。
• Team Share Ops：不同產品開發團隊之間共享一個Ops。在這種情況下 Ops 團隊就是一個平臺團隊。

為新組織設立目標 做團隊合并之前，要為新組織設立目標，如下：

• 單一的產品開發團隊及運維團隊，各地區共享，由統一的產品經理協調各地的開發任務和業務需求。
• 每個地區可自有開發團隊，但都由馬來西亞開發團隊來統一管理，所有運維都由馬來西亞團隊來支持。
• 在所有公司構建DevOps文化及機制，從 Team Own Ops 向 Team Share Ops 變化。
• 提升各個國家的Dev / Ops 水平，當水平達到一致，便可通過DevOps這個中間橋梁打通。

用DevOps加速團隊之間合并的進程

雖然IT團隊來自不同的國家，分布在不同的地理位置，他們的文化背景不同，說著不同的英語方言，但是大家的技術棧是相同的。

一方面，我們通過 Zoom 構建起了每天的在線視頻會議，及時同步各個團隊之間的狀況。另一方面，我們遵守著同樣的開發規則。 其中，測試驅動開發（TDD）在這樣的分布式團隊中十分重要。雖然對編程語言和技術框架的理解不同，但是自動化測試為開發人員構建出了統一的理解。這樣就使得每個團隊，每個成員去設計、實現自動化測試。

一方面，用測試作為對需求的理解，減少和降低了不一致性，此外，通過測試驅動開發可以保證代碼品質，進而提升程序員的編碼水平。此外，自動化測試在這里就相當于一種代碼質量的標準， 組織被合并之后，架構也要隨之改變，這時就要著手做架構遷移。可以用基礎設施即代碼把自動化作為一種制度去提升整體運行效果。

系統架構的遷移實踐系統架構遷移要在了解當前組織架構現狀的前提下，制定架構的目標、設計遷移策略。這三方面落實后，才能為新組織設計新架構。

架構要盡量設計要設定***要求，這里不要將就現有人員的能力/精力，但是要規劃成本，成本規劃里不光要考慮遷移成本，還要考慮遷移后的維護成本。這樣，有了***的要求和標準，可以引導大家為共同的結論和方向一起努力，既可以提升個人及團隊的技術能力，也是提升DevOps合作的過程，因為好的架構一定是和多方利益相關者在不斷溝通下形成的。通過不斷的開發團隊溝通，解決開發痛點，來主動提升 Ops 團隊的合作意識。所以，DevOps不僅是自動化，更是在磨合和共識團隊合作的價值觀和工作方式。

當前的組織與系統架構存在的問題

當組織和產品進行合并之后，不同的地區多系統的運維就變成了單一系統的運維。因此，很多運維人員不再被需要，在現在的案例中，僅剩四名運維工程師，剩下的運維工程師相繼離職，運維工作由技術負責人兼任。 這里遇到的問題是，如此少量的運維人員，如何要去維護大量技術棧/語言/業務各異的站點。因為產品簡單了，但架構復雜了，運維的環節和結點更多了。

此外，為了避免賬戶單點，平均每個系統至少要有三個AWS賬戶：開發環境、測試環境及生產環境。這樣一來，三個人維護二十多個賬戶是一種浪費，還需要做賬戶合并。 這三個運維人員人還需要應對風格各異的其它遺留系統，因為每一個國家的系統都分別由不同的架構師主導，對于僅三人的運維團隊來說也是非常大的挑戰。 盡管收購的企業核心業務相似，但每個國家的現狀、市場條件、用戶群都不一樣，所以仍然需要一部分本地定制化業務。 總之，在系統架構方面存在的主要問題如下：

• 每個國家的架構都由不同架構師設計，所以會留下很多隱藏知識，以至于維護困難。
• 基礎設施即代碼已在一些IT團隊中被使用，卻沒有用好，存在很多硬編碼。
• 舊架構在更新一個應用時，就需要把整個架構全部更新，并非部分更新。

架構遷移的目標

綜合當前新組織的現狀與舊架構的問題，制定架構遷移目標如下：

• 實現用基礎設施即代碼管理所有的基礎設施，因為舊架構還有些應用在機房裸機上運行，并且需要手動安裝。
• 現有基礎設施架構全部遷移到云上。
• 基礎設施的管理要規范化，可以把基礎設施即代碼看成一套制度，用來規范運維人員如何操作基礎設施。
• 給所有運維人員、開發工程師提供統一界面，讓他們基于基礎設施即代碼之上進行應用開發，進而實現部分更新，而不是全部更新。

實現能力和組織結構的遷移，基礎設施即代碼首先作為一個制度可保證以上幾點。基礎設施即代碼一旦作為制度，在執行的過程中，要做到的***一點就是能力的提升，即把基礎設施變成一種產品。 如何把基礎設施變成一種產品？首先是把基礎設施架構經驗在不同團隊中復用，讓不同國家、程序員、運維人員獲得更安全，更穩定，更靈活的架構。其次是實現高度自動化，可以快速建設和定制。再次是要做到關注點分離，根據場景把變更縮小在一定的范圍里。***，要把開發和各環境做到抽象一致性，便于不同團隊能夠在不同環境中做到無縫切換。

架構的遷移策略

架構遷移有兩大原則：一是最少的變更，實現做到只做一個簡單的變更，就完成遷移；二是最小的影響，就是減少架構變更造成的不良影響。 架構遷移的整個策略如下：

• 將遺留系統應用按照（架構/應用/數據）進行封裝。
• 用基礎設施即代碼構建一套新的架構，構建可復用架構模型。
• 對架構/應用/數據這三部分別用該腳本實施自動化遷移。
• 測試完成后切換總域名，切換子域名。
• 兩周過后，遺留系統下線。

此架構策略除需要手動切換域名之外，其余全部實現自動化，主要涉及技術如下：

• 用 Ansible + Cloudformation 封裝并構造新的基礎設施。基礎設施要能做到隨時可以完全恢復。
• 全量數據 dump / import，自動化備份到 s3 上。減少數據庫的狀態。
• 用 Docker 封裝 wordpress 應用。不同的國家用不同的主題和插件組合完成。
• 用 cdn + nginx + wordpress 共同做 301、302 跳轉。要為每個角色做好區分。
• 用腳本做遷移，遷移腳本分類（開發/測試/生產）管理。
• 切換域名指向（手動）。

為新的組織結構設計架構

對組織進行重建，確定新組織對應架構的目標和策略之后，緊接著就是根據使用場景，設計基礎設施即代碼的架構，實現整個架構自動的搭建和還原。然后，根據使用場景設計安全策略，避免人為操作，減少人為故障。 顧宇老師認為，基礎設施即代碼和基礎設施是類和對象的關系。通過定制化的模板結合不同的場景產生不同的基礎設施實例。一方面統一了架構語言，另一方面減少了不經審計的認為操作。此外， 可以采用面向對象原則進行邏輯分層，隔離不同場景的關注點。例如：持續交付關注Docker 鏡像的部署和變更，應用維護關注日志的查詢和操作。

寫在***

在該案例中，利用基礎設施即代碼技術有幾個關鍵要點，總結如下：

• 架構遷移要為組織結構遷移服務。
• 把自動化和基礎設施即代碼當做制度使用（康威定理和逆定理）。
• 把基礎設施即代碼當做一個產品開發。
• 安全的架構和架構的安全。
• 基礎設施邏輯分層。
• 基礎設施即代碼本質上是一套類庫，從面向對象的原則考慮基礎設施的設計。
• 構建每日可用架構。

由于篇幅原因，還有眾多相關細節如、沒有一一納入文章中，想要了解更過內容的開發者，可查看 視頻與PPT 【講師簡介】 

顧宇，Thought Works 高級咨詢師。專注于 DevOps、持續交付，微服務以及全功能產品團隊的設計、實踐、落地以及經驗推廣。并持續在多個專業平臺和媒體發表相關文章，受多個行業大會邀請發表相關演講。

在加入 ThoughtWorks 之前，曾經參與中國移動 10086 呼叫中心以及中國聯通省級 BOSS 系統的研發、實施和割接。任項目經理，維護經理，開發工程師等職務，擁有豐富的大型 IT 系統小型機生產環境實戰經驗。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】