跨國互聯(lián)網(wǎng)公司統(tǒng)一的IT管理方案

1、 跨國互聯(lián)網(wǎng)公司統(tǒng)一的IT管理方案特別是涉及不同的企業(yè)文化、技術(shù)能力甚至是不同的國家法律法規(guī)上的融合，存在更多看不到的隱形成本。本文介紹如何通過 DevOps 的基礎設施即代碼實踐，把架構(gòu)以及開發(fā)/運維實踐和規(guī)則固化為配置和代碼。讓所有的團隊和成員能夠依照同樣的規(guī)則進行開發(fā)和運維；通過自動化的手段加速團隊、產(chǎn)品和架構(gòu)的融合過程，提升整個組織的技術(shù)水平。減少組織間的溝通摩擦?？鐕ヂ?lián)網(wǎng)公司并購案例案例梗概某企業(yè)收購了分布在泰國、馬來西亞、印度尼西亞、新家坡等地的幾家東南亞擁有相同業(yè)務的互聯(lián)網(wǎng)公司。但如何在多國家、多語言文化的情況下，進行分布式 IT 敏捷產(chǎn)品團隊的合并、步調(diào)一致的工作和實現(xiàn)統(tǒng)一的

2、管理成為難題。剖析組織現(xiàn)狀既要保留各個國家的業(yè)務團隊，又要集中管理 IT 團隊，首當其沖的是剖析組織現(xiàn)狀。那么，做架構(gòu)遷移要先了解哪些組織現(xiàn)狀呢？康威定律原話：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。這句話中“constrained”的意思是強制。也就是說，當系統(tǒng)架構(gòu)與組織架構(gòu)不匹配時，系統(tǒng)結(jié)構(gòu)會被強制轉(zhuǎn)化成與組織架構(gòu)一致。要做到組織架構(gòu)和基礎設施架構(gòu)保

3、持一致，就需要根據(jù)未來的組織結(jié)構(gòu)設計系統(tǒng)架構(gòu)，減少系統(tǒng)架構(gòu)演進中的適應性浪費。如下圖，是合并前架構(gòu)的情況：如圖中所示，每個國家的公司運營著自己的網(wǎng)站。其中每一公司都有一部分是用 WordPress 運營的。雖然都是 WordPress，但應用架構(gòu)和使用方式上存在著諸多的差異。我們首先是要識別出這種差異。而這種差異不僅僅是技術(shù)上的，還有組織上的。并購并不僅僅是把團隊合并到一起就能解決問題，而是要把多國、多語言、多站點，變成多國、多語言、單站點。通過一個站點來支撐多個地區(qū)的業(yè)務，這里選擇馬來西亞作為這個站點進行舉例。那么，組織架構(gòu)就會辦成如下圖所示：當組織架構(gòu)變成多國、多語言、單站點，那么所對應的

4、就是一個 IT 團隊。如圖可以看到把 Dev、Ops 分開來表示，這樣的組織結(jié)構(gòu)和 DevOps 有什么關系呢？這就需要了解下 DevOps 的兩種組織形式：Team OwnOps：團隊內(nèi)自有的 Ops，把 Ops 當做團隊成員，實現(xiàn)開發(fā)和運維合作。Team ShareOps：不同產(chǎn)品開發(fā)團隊之間共享一個 Ops。在這種情況下 Ops 團隊就是一個平臺團隊。為新組織設立目標做團隊合并之前，要為新組織設立目標，如下：單一的產(chǎn)品開發(fā)團隊及運維團隊，各地區(qū)共享，由統(tǒng)一的產(chǎn)品經(jīng)理協(xié)調(diào)各地的開發(fā)任務和業(yè)務需求。每個地區(qū)可自有開發(fā)團隊，但都由馬來西亞開發(fā)團隊來統(tǒng)一管理，所有運維都由馬來西亞團隊來支持。在所

5、有公司構(gòu)建 DevOps 文化及機制，從 Team Own Ops 向 Team Share Ops 變化。提升各個國家的 Dev / Ops 水平，當水平達到一致，便可通過 DevOps 這個中間橋梁打通。用 DevOps 加速團隊之間合并的進程雖然 IT 團隊來自不同的國家，分布在不同的地理位置，他們的文化背景不同，說著不同的英語方言，但是大家的技術(shù)棧是相同的。一方面，我們通過 Zoom 構(gòu)建起了每天的在線視頻會議，及時同步各個團隊之間的狀況；另一方面，我們遵守著同樣的開發(fā)規(guī)則。其中，測試驅(qū)動開發(fā)（TDD）在這樣的分布式團隊中十分重要。雖然對編程語言和技術(shù)框架的理解不同，但是自動化測試為開

6、發(fā)人員構(gòu)建出了統(tǒng)一的理解。這樣就使得每個團隊，每個成員去設計、實現(xiàn)自動化測試。一方面，用測試作為對需求的理解，減少和降低了不一致性；此外，通過測試驅(qū)動開發(fā)可以保證代碼品質(zhì)，進而提升程序員的編碼水平。自動化測試在這里就相當于一種代碼質(zhì)量的標準，組織被合并之后，架構(gòu)也要隨之改變，這時就要著手做架構(gòu)遷移?？梢杂没A設施即代碼把自動化作為一種制度去提升整體運行效果。系統(tǒng)架構(gòu)的遷移實踐系統(tǒng)架構(gòu)遷移要在了解當前組織架構(gòu)現(xiàn)狀的前提下，制定架構(gòu)的目標、設計遷移策略。這三方面落實后，才能為新組織設計新架構(gòu)。架構(gòu)要盡量設計為設定的最高要求，這里不要將就現(xiàn)有人員的能力/精力，但是要規(guī)劃成本，成本規(guī)劃里不光要考慮遷移

7、成本，還要考慮遷移后的維護成本。這樣，有了最高的要求和標準，可以引導大家為共同的結(jié)論和方向一起努力，既可以提升個人及團隊的技術(shù)能力，也是提升 DevOps 合作的過程，因為好的架構(gòu)一定是和多方利益相關者在不斷溝通下形成的。通過不斷的開發(fā)團隊溝通，解決開發(fā)痛點，來主動提升 Ops 團隊的合作意識。所以，DevOps 不僅是自動化，更是在磨合和共識團隊合作的價值觀和工作方式。當前的組織與系統(tǒng)架構(gòu)存在的問題當組織和產(chǎn)品進行合并之后，不同的地區(qū)多系統(tǒng)的運維就變成了單一系統(tǒng)的運維。因此，很多運維人員不再被需要，在現(xiàn)在的案例中，僅剩四名運維工程師，剩下的運維工程師相繼離職，運維工作由技術(shù)負責人兼任。這里遇

8、到的問題是，如此少量的運維人員，如何維護大量技術(shù)棧/語言/業(yè)務各異的站點。因為產(chǎn)品簡單了，但架構(gòu)復雜了，運維的環(huán)節(jié)和結(jié)點更多了。此外，為了避免賬戶單點，平均每個系統(tǒng)至少要有三個 AWS 賬戶：開發(fā)環(huán)境、測試環(huán)境及生產(chǎn)環(huán)境。這樣一來，三個人維護二十多個賬戶是一種浪費，還需要做賬戶合并。這三個運維人員還需要應對風格各異的其他遺留系統(tǒng)，因為每一個國家的系統(tǒng)都分別由不同的架構(gòu)師主導，對于僅三人的運維團隊來說也是非常大的挑戰(zhàn)。盡管收購的企業(yè)核心業(yè)務相似，但每個國家的現(xiàn)狀、市場條件、用戶群都不一樣，所以仍然需要一部分本地定制化業(yè)務?？傊?，在系統(tǒng)架構(gòu)方面存在的主要問題如下：每個國家的架構(gòu)都由不同架構(gòu)師設計，

9、所以會留下很多隱藏知識，以至于維護困難。基礎設施即代碼已在一些 IT 團隊中被使用，卻沒有用好，存在很多硬編碼。舊架構(gòu)在更新一個應用時，就需要把整個架構(gòu)全部更新，并非部分更新。架構(gòu)遷移的目標綜合當前新組織的現(xiàn)狀與舊架構(gòu)的問題，制定架構(gòu)遷移目標如下：實現(xiàn)用基礎設施即代碼管理所有的基礎設施，因為舊架構(gòu)還有些應用在機房裸機上運行，并且需要手動安裝?，F(xiàn)有基礎設施架構(gòu)全部遷移到云上?；A設施的管理要規(guī)范化，可以把基礎設施即代碼看成一套制度，用來規(guī)范運維人員如何操作基礎設施。給所有運維人員、開發(fā)工程師提供統(tǒng)一界面，讓他們基于基礎設施即代碼之上進行應用開發(fā)，進而實現(xiàn)部分更新，而不是全部更新。實現(xiàn)能力和組織結(jié)

10、構(gòu)的遷移，基礎設施即代碼首先作為一個制度可保證以上幾點?；A設施即代碼一旦作為制度，在執(zhí)行的過程中，要做到的最后一點就是能力的提升，即把基礎設施變成一種產(chǎn)品。如何把基礎設施變成一種產(chǎn)品？步驟如下：把基礎設施架構(gòu)經(jīng)驗在不同團隊中復用，讓不同國家、程序員、運維人員獲得更安全，更穩(wěn)定，更靈活的架構(gòu)。實現(xiàn)高度自動化，可以快速建設和定制。要做到關注點分離，根據(jù)場景把變更縮小在一定的范圍里。要把開發(fā)和各環(huán)境做到抽象一致性，便于不同團隊能夠在不同環(huán)境中做到無縫切換。架構(gòu)的遷移策略架構(gòu)遷移有兩大原則：最少的變更，實現(xiàn)做到只做一個簡單的變更，就完成遷移。最小的影響，就是減少架構(gòu)變更造成的不良影響。架構(gòu)遷移的整個

11、策略如下：將遺留系統(tǒng)應用按照（架構(gòu)/應用/數(shù)據(jù)）進行封裝。用基礎設施即代碼構(gòu)建一套新的架構(gòu)，構(gòu)建可復用架構(gòu)模型。對架構(gòu)/應用/數(shù)據(jù)這三部分別用該腳本實施自動化遷移。測試完成后切換總域名，切換子域名。兩周過后，遺留系統(tǒng)下線。此架構(gòu)策略除需要手動切換域名之外，其余全部實現(xiàn)自動化。主要涉及技術(shù)如下：用 Ansible + Cloudformation 封裝并構(gòu)造新的基礎設施?；A設施要能做到隨時可以完全恢復。全量數(shù)據(jù) dump / import，自動化備份到 s3 上，減少數(shù)據(jù)庫的狀態(tài)。用 Docker 封裝 wordpress 應用。不同的國家用不同的主題和插件組合完成。用 cdn + nginx

12、 + wordpress 共同做 301、302 跳轉(zhuǎn)，要為每個角色做好區(qū)分。用腳本做遷移，遷移腳本分類（開發(fā)/測試/生產(chǎn)）管理。切換域名指向（手動）。為新的組織結(jié)構(gòu)設計架構(gòu)對組織進行重建，確定新組織對應架構(gòu)的目標和策略之后，緊接著就是根據(jù)使用場景，設計基礎設施即代碼的架構(gòu)，實現(xiàn)整個架構(gòu)自動的搭建和還原。然后，根據(jù)使用場景設計安全策略，避免人為操作，減少人為故障。顧宇老師認為，基礎設施即代碼和基礎設施是類和對象的關系。通過定制化的模板結(jié)合不同的場景產(chǎn)生不同的基礎設施實例。一方面統(tǒng)一了架構(gòu)語言；另一方面減少了不經(jīng)審計的認為操作。此外，可以采用面向?qū)ο笤瓌t進行邏輯分層，隔離不同場景的關注點。例如：持續(xù)交付關注 D