建站
咨詢
售后
建站咨詢
新聞中心
【稿件】互聯(lián)網(wǎng)企業(yè)的并購不僅是組織結構的融合，更是產(chǎn)品架構和產(chǎn)品團隊的融合。特別是涉及不同的企業(yè)文化、技術能力甚至是不同的國家法律法規(guī)上的融合，存在更多看不到的隱形成本。
屯昌ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
近日，由主辦的第十六期以“Tech Neo”為主題的技術沙龍在北京舉行，此次活動邀請了來自Thought Works 高級咨詢師顧宇老師。他分享了一個東南亞互聯(lián)網(wǎng)企業(yè)并購中的DevOps 促進并購的實施案例，即通過在 AWS上使用 Ansible和CloudFormation作為基礎設施即代碼的工具實現(xiàn)產(chǎn)品架構的遷移。
本文介紹如何通過 DevOps的基礎設施即代碼實踐，把架構以及開發(fā)/運維實踐和規(guī)則固化為配置和代碼。讓所有的團隊和成員能夠依照同樣的規(guī)則進行開發(fā)和運維；通過自動化的手段加速團隊、產(chǎn)品和架構的融合過程，提升整個組織的技術水平。減少組織間的溝通摩擦。
跨國互聯(lián)網(wǎng)公司并購案例
案例梗概：某企業(yè)收購了分布在泰國、馬來西亞、印度尼西亞、新家坡等地的幾家東南亞擁有相同業(yè)務的互聯(lián)網(wǎng)公司。但如何在多國家、多語言文化的情況下，進行分布式IT敏捷產(chǎn)品團隊的合并、步調(diào)一致的工作和實現(xiàn)統(tǒng)一的管理成為難題。
剖析組織現(xiàn)狀
既要保留各個國家的業(yè)務團隊，又要集中管理IT團隊，首當其沖的是剖析組織現(xiàn)狀。那么，做架構遷移要先了解哪些組織現(xiàn)狀呢？ ″
康威定律原話：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。
這句話中“constrained”的意思是強制。也就是說，當系統(tǒng)架構與組織架構不匹配時，系統(tǒng)結構會被強制轉化成與組織架構一致。要做到組織架構和基礎設施架構保持一致，就需要根據(jù)未來的組織結構設計系統(tǒng)架構，減少系統(tǒng)架構演進中的適應性浪費。
如下圖，是合并前架構的情況：
如圖中所示，每個國家的公司運營著自己的網(wǎng)站。其中每一公司都有一部分是用WordPress運營的。雖然都是 WordPress，但應用架構和使用方式上存在著諸多的差異。我們首先是要識別出這種差異。而這種差異不僅僅是技術上的，還有組織上的。 并購并不僅僅是把團隊合并到一起就能解決問題，而是要把多國、多語言、多站點，變成多國、多語言、單站點。通過一個站點來支撐多個地區(qū)的業(yè)務，這里選擇馬來西亞作為這個站點進行舉例。
那么，組織架構就會辦成如下圖所示：
當組織架構變成多國、多語言、單站點，那么所對應的就是一個IT團隊。如圖可以看到把Dev、Ops分開來表示，這樣的組織結構和DevOps有什么關系呢？這就需要了解下DevOps的兩種組織形式：
- Team Own Ops：團隊內(nèi)自有的Ops，把Ops當做團隊成員，實現(xiàn)開發(fā)和運維合作。
- Team Share Ops：不同產(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)一管理，所有運維都由馬來西亞團隊來支持。
- 在所有公司構建DevOps文化及機制，從 Team Own Ops 向 Team Share Ops 變化。
- 提升各個國家的Dev / Ops 水平，當水平達到一致，便可通過DevOps這個中間橋梁打通。
用DevOps加速團隊之間合并的進程
雖然IT團隊來自不同的國家，分布在不同的地理位置，他們的文化背景不同，說著不同的英語方言，但是大家的技術棧是相同的。
一方面，我們通過 Zoom 構建起了每天的在線視頻會議，及時同步各個團隊之間的狀況。另一方面，我們遵守著同樣的開發(fā)規(guī)則。 其中，測試驅(qū)動開發(fā)（TDD）在這樣的分布式團隊中十分重要。雖然對編程語言和技術框架的理解不同，但是自動化測試為開發(fā)人員構建出了統(tǒng)一的理解。這樣就使得每個團隊，每個成員去設計、實現(xiàn)自動化測試。
一方面，用測試作為對需求的理解，減少和降低了不一致性，此外，通過測試驅(qū)動開發(fā)可以保證代碼品質(zhì)，進而提升程序員的編碼水平。此外，自動化測試在這里就相當于一種代碼質(zhì)量的標準， 組織被合并之后，架構也要隨之改變，這時就要著手做架構遷移?？梢杂没A設施即代碼把自動化作為一種制度去提升整體運行效果。
系統(tǒng)架構的遷移實踐系統(tǒng)架構遷移要在了解當前組織架構現(xiàn)狀的前提下，制定架構的目標、設計遷移策略。這三方面落實后，才能為新組織設計新架構。
架構要盡量設計要設定***要求，這里不要將就現(xiàn)有人員的能力/精力，但是要規(guī)劃成本，成本規(guī)劃里不光要考慮遷移成本，還要考慮遷移后的維護成本。這樣，有了***的要求和標準，可以引導大家為共同的結論和方向一起努力，既可以提升個人及團隊的技術能力，也是提升DevOps合作的過程，因為好的架構一定是和多方利益相關者在不斷溝通下形成的。通過不斷的開發(fā)團隊溝通，解決開發(fā)痛點，來主動提升 Ops 團隊的合作意識。所以，DevOps不僅是自動化，更是在磨合和共識團隊合作的價值觀和工作方式。
當前的組織與系統(tǒng)架構存在的問題
當組織和產(chǎn)品進行合并之后，不同的地區(qū)多系統(tǒng)的運維就變成了單一系統(tǒng)的運維。因此，很多運維人員不再被需要，在現(xiàn)在的案例中，僅剩四名運維工程師，剩下的運維工程師相繼離職，運維工作由技術負責人兼任。 這里遇到的問題是，如此少量的運維人員，如何要去維護大量技術棧/語言/業(yè)務各異的站點。因為產(chǎn)品簡單了，但架構復雜了，運維的環(huán)節(jié)和結點更多了。
此外，為了避免賬戶單點，平均每個系統(tǒng)至少要有三個AWS賬戶：開發(fā)環(huán)境、測試環(huán)境及生產(chǎn)環(huán)境。這樣一來，三個人維護二十多個賬戶是一種浪費，還需要做賬戶合并。 這三個運維人員人還需要應對風格各異的其它遺留系統(tǒng)，因為每一個國家的系統(tǒng)都分別由不同的架構師主導，對于僅三人的運維團隊來說也是非常大的挑戰(zhàn)。 盡管收購的企業(yè)核心業(yè)務相似，但每個國家的現(xiàn)狀、市場條件、用戶群都不一樣，所以仍然需要一部分本地定制化業(yè)務。 總之，在系統(tǒng)架構方面存在的主要問題如下：
- 每個國家的架構都由不同架構師設計，所以會留下很多隱藏知識，以至于維護困難。
- 基礎設施即代碼已在一些IT團隊中被使用，卻沒有用好，存在很多硬編碼。
- 舊架構在更新一個應用時，就需要把整個架構全部更新，并非部分更新。
架構遷移的目標
綜合當前新組織的現(xiàn)狀與舊架構的問題，制定架構遷移目標如下：
- 實現(xiàn)用基礎設施即代碼管理所有的基礎設施，因為舊架構還有些應用在機房裸機上運行，并且需要手動安裝。
- 現(xiàn)有基礎設施架構全部遷移到云上。
- 基礎設施的管理要規(guī)范化，可以把基礎設施即代碼看成一套制度，用來規(guī)范運維人員如何操作基礎設施。
- 給所有運維人員、開發(fā)工程師提供統(tǒng)一界面，讓他們基于基礎設施即代碼之上進行應用開發(fā)，進而實現(xiàn)部分更新，而不是全部更新。
實現(xiàn)能力和組織結構的遷移，基礎設施即代碼首先作為一個制度可保證以上幾點。基礎設施即代碼一旦作為制度，在執(zhí)行的過程中，要做到的***一點就是能力的提升，即把基礎設施變成一種產(chǎn)品。 如何把基礎設施變成一種產(chǎn)品？首先是把基礎設施架構經(jīng)驗在不同團隊中復用，讓不同國家、程序員、運維人員獲得更安全，更穩(wěn)定，更靈活的架構。其次是實現(xiàn)高度自動化，可以快速建設和定制。再次是要做到關注點分離，根據(jù)場景把變更縮小在一定的范圍里。***，要把開發(fā)和各環(huán)境做到抽象一致性，便于不同團隊能夠在不同環(huán)境中做到無縫切換。
架構的遷移策略
架構遷移有兩大原則：一是最少的變更，實現(xiàn)做到只做一個簡單的變更，就完成遷移；二是最小的影響，就是減少架構變更造成的不良影響。 架構遷移的整個策略如下：
- 將遺留系統(tǒng)應用按照（架構/應用/數(shù)據(jù)）進行封裝。
- 用基礎設施即代碼構建一套新的架構，構建可復用架構模型。
- 對架構/應用/數(shù)據(jù)這三部分別用該腳本實施自動化遷移。
- 測試完成后切換總域名，切換子域名。
- 兩周過后，遺留系統(tǒng)下線。
此架構策略除需要手動切換域名之外，其余全部實現(xiàn)自動化，主要涉及技術如下：
- 用 Ansible + Cloudformation 封裝并構造新的基礎設施?；A設施要能做到隨時可以完全恢復。
- 全量數(shù)據(jù) dump / import，自動化備份到 s3 上。減少數(shù)據(jù)庫的狀態(tài)。
- 用 Docker 封裝 wordpress 應用。不同的國家用不同的主題和插件組合完成。
- 用 cdn + nginx + wordpress 共同做 301、302 跳轉。要為每個角色做好區(qū)分。
- 用腳本做遷移，遷移腳本分類（開發(fā)/測試/生產(chǎn)）管理。
- 切換域名指向（手動）。
為新的組織結構設計架構
對組織進行重建，確定新組織對應架構的目標和策略之后，緊接著就是根據(jù)使用場景，設計基礎設施即代碼的架構，實現(xiàn)整個架構自動的搭建和還原。然后，根據(jù)使用場景設計安全策略，避免人為操作，減少人為故障。 顧宇老師認為，基礎設施即代碼和基礎設施是類和對象的關系。通過定制化的模板結合不同的場景產(chǎn)生不同的基礎設施實例。一方面統(tǒng)一了架構語言，另一方面減少了不經(jīng)審計的認為操作。此外， 可以采用面向?qū)ο笤瓌t進行邏輯分層，隔離不同場景的關注點。例如：持續(xù)交付關注Docker 鏡像的部署和變更，應用維護關注日志的查詢和操作。
寫在***
在該案例中，利用基礎設施即代碼技術有幾個關鍵要點，總結如下：
- 架構遷移要為組織結構遷移服務。
- 把自動化和基礎設施即代碼當做制度使用（康威定理和逆定理）。
- 把基礎設施即代碼當做一個產(chǎn)品開發(fā)。
- 安全的架構和架構的安全。
- 基礎設施邏輯分層。
- 基礎設施即代碼本質(zhì)上是一套類庫，從面向?qū)ο蟮脑瓌t考慮基礎設施的設計。
- 構建每日可用架構。
由于篇幅原因，還有眾多相關細節(jié)如、沒有一一納入文章中，想要了解更過內(nèi)容的開發(fā)者，可查看 視頻與PPT 【講師簡介】
顧宇，Thought Works 高級咨詢師。專注于 DevOps、持續(xù)交付，微服務以及全功能產(chǎn)品團隊的設計、實踐、落地以及經(jīng)驗推廣。并持續(xù)在多個專業(yè)平臺和媒體發(fā)表相關文章，受多個行業(yè)大會邀請發(fā)表相關演講。
在加入 ThoughtWorks 之前，曾經(jīng)參與中國移動 10086 呼叫中心以及中國聯(lián)通省級 BOSS 系統(tǒng)的研發(fā)、實施和割接。任項目經(jīng)理，維護經(jīng)理，開發(fā)工程師等職務，擁有豐富的大型 IT 系統(tǒng)小型機生產(chǎn)環(huán)境實戰(zhàn)經(jīng)驗。
【原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為.com】
新聞標題：跨國互聯(lián)網(wǎng)公司并購中用基礎設施即代碼進行架構遷移
鏈接地址：http://www.5511xx.com/article/cciejsp.html
