DevOps轉(zhuǎn)型的動機

我們的客戶是一家海外本土***的金融保險集團，他們在發(fā)展到一定規(guī)模以后，意識到自己就像一頭笨重的大象，舉步維艱，通過對整個交付流程的思考和分析，發(fā)現(xiàn)了以下一些嚴重影響交付速度的問題：

1. 一些好的關(guān)于產(chǎn)品改善和創(chuàng)新的想法很難落地。涉及到一些遺留系統(tǒng)的配合：調(diào)整、部署、擴展等，使團隊對發(fā)布沒有信心。新的服務(wù)或者應(yīng)用的構(gòu)建，很難快速上線，被卡在了生產(chǎn)環(huán)境部署階段。
2. 各種不同種類的應(yīng)用、服務(wù)的部署方式和流程不一致。運維部門作為一個支持部門，很難為大量團隊提供快速反應(yīng)。運維人員對于需要部署和運營環(huán)境之上的產(chǎn)品也不夠了解。
3. 微服務(wù)運營過程中，交付團隊難以做到快速集成和部署。運維團隊對微服務(wù)的部署運維方式不理解，依舊老瓶裝新藥，很難適配新架構(gòu)下的交付模式。開發(fā)團隊大多關(guān)注代碼和架構(gòu)，對于產(chǎn)品如何能在生產(chǎn)環(huán)境穩(wěn)定運行、需要考慮哪些安全性和可持續(xù)性的因素并不是很了解。

問題分析和挑戰(zhàn)

通過對這些問題和各個團隊反饋的深入分析，發(fā)現(xiàn)其中***的瓶頸在于交付團隊與運維部門之間的各種依賴和溝通浪費，而這個瓶頸又是解決大多數(shù)問題的前提。

我們將瓶頸具象化后(如上圖)，可以看到兩種團隊之間其實是存在一堵墻的，一是因為傳統(tǒng)的部署流程非常繁瑣和低效。二是因為兩種角色關(guān)注點和目標(biāo)的不一致。

如果在這樣的情況下，想實現(xiàn)微服務(wù)架構(gòu)轉(zhuǎn)型，實現(xiàn)更快速和安全的交付，只會更快的暴露出這堵墻引起的各種問題。開發(fā)階段，系統(tǒng)的架構(gòu)和依賴環(huán)境都是Developer說了算，對生產(chǎn)環(huán)境的關(guān)注度不高。部署、發(fā)布階段，Operations會考慮如何構(gòu)建一套穩(wěn)定的基礎(chǔ)設(shè)施，又如何去部署和運維開發(fā)的產(chǎn)物，但是往往對于產(chǎn)物的了解不充分，對于產(chǎn)物的周邊生態(tài)和與它們關(guān)系的了解也不夠。

那么引入DevOps文化，消除開發(fā)與運維之間的壁壘，逐步打造更高效的交付流程就成為我們破局的關(guān)鍵，那我們應(yīng)該怎么做呢?

改革之初，我們發(fā)現(xiàn)并去嘗試了Bimodel(雙模IT)，我們看看它是否能解決我們的問題：

[[199654]]

先簡單介紹一下什么是雙模IT:

它將IT系統(tǒng)分成了兩種模式:

1. 一種是新型的數(shù)字化、高市場適應(yīng)性的IT，這部分業(yè)務(wù)聚焦企業(yè)新市場和業(yè)務(wù)的開拓，創(chuàng)新和發(fā)展，強調(diào)IT自身對于市場的高適應(yīng)力。
2. 另外一種模式下，我們則需要穩(wěn)固發(fā)展，對于傳統(tǒng)模式我們傾向于更加嚴謹和標(biāo)準的流程去保護現(xiàn)有業(yè)務(wù)，穩(wěn)定性比速度更加重要。

我們從采用這樣一種模式的實踐案例中發(fā)現(xiàn)：組織內(nèi)部會出現(xiàn)連兩種速度的交付流程，好的情況可能是采用敏捷開發(fā)流程的交付線，有著快速的交付能力，相反，對于繼續(xù)采用傳統(tǒng)開發(fā)流程和運維方式的團隊，保持著穩(wěn)定但低效的交付能力。

從業(yè)界很多公司的現(xiàn)狀和發(fā)展趨勢來看，雙模IT確實是很多組織存在的現(xiàn)狀或是必然經(jīng)歷的過程，但不是一個好的模式，從實際的交付過程來看，存在4點問題：

1. 雙模IT的劃分方式更多是基于軟件系統(tǒng)，而不是從業(yè)務(wù)活動出發(fā)進行的，所有軟件系統(tǒng)的交付都應(yīng)該是面向業(yè)務(wù)價值的。
2. 雙模IT會讓我們誤以為速度的提升會引起質(zhì)量的下降，但是對于我們在ThoughtWorks的很多敏捷實踐中學(xué)到的：隨著交付的推進，質(zhì)量內(nèi)建是團隊共同負責(zé)和持續(xù)改進的重點。交付速度的提升，往往都伴隨著質(zhì)量的保障，而不是忽視質(zhì)量。
3. 實際生產(chǎn)中，一個新的產(chǎn)品或者功能往往會依賴很多遺留系統(tǒng)提供的服務(wù)，如果它們僅僅只能達到穩(wěn)定和低效的交付，對企業(yè)來說對市場整體的響應(yīng)能力也會越來越低。
4. 企業(yè)的創(chuàng)新不僅僅只是從零創(chuàng)造一個新的產(chǎn)品，還有很多機遇現(xiàn)有的資源。一個新的系統(tǒng)和功能往往不僅會既涉及到新服務(wù)、應(yīng)用的創(chuàng)建，也會涉及到遺留系統(tǒng)的修改，調(diào)整和改造。

由此可見雙模IT是在以一種試圖掩蓋問題的方式來逃避目前最重要的問題：開發(fā)和運維之間的壁壘。感覺像是一個病人先是放棄治療，然后又努力的尋找延長壽命的方法，有些隱患終會爆發(fā)。

打造自服務(wù)持續(xù)交付

緊接著，我們開始采用了一種看似不可行的方式開啟了DevOps轉(zhuǎn)型，建立公有DevOps團隊。有很多人可能會說這是一種反模式，怎么可能會建立一個團隊專做DevOps相關(guān)的事情，那和以前的運維部門又有什么區(qū)別?DevOps提倡的Dev與Ops高頻度合作的文化是不是就無法大面積傳播了?

因此我們需要很明確的定義我們對這個團隊的期望和它的職責(zé)是什么，它是怎樣和交付團隊合作，影響交付團隊，最終能讓DevOps的文化可以大面積傳播。這個團隊的目標(biāo)是要像杠桿一樣，翹起更大面積的DevOps變革。

所以我們認為公有DevOps團隊?wèi)?yīng)該與其它的端到端交付團隊的人員構(gòu)成是一樣的。不同的只是目標(biāo)和價值，主要體現(xiàn)在幫助更多的團隊植入DevOps文化、優(yōu)化持續(xù)交付流程。最終達到的目標(biāo)是每個團隊都可以自治，每個團隊都可以進行端到端的開發(fā)、測試和部署，并可以自驅(qū)動的持續(xù)改進。與此同時，這個團隊不僅僅只是為交付團隊提供更多涉及基礎(chǔ)設(shè)施、持續(xù)交付流水線、部署等活動所需要的自動化能力，還會支撐交付團隊根據(jù)自身的上下文去定制和規(guī)劃自己的持續(xù)交付流程和部署策略等。

[[199655]]

(圖片來自：http://t.cn/R9jnzHR)

現(xiàn)在，相比于DevOps團隊的叫法，我們更愿意稱呼這個團隊為Platform團隊，一個原因是我之前所說的避免被錯誤理解，另一個原因是隨著各個交付團隊逐步實現(xiàn)自服務(wù)持續(xù)交付，這個專有團隊也有了更高的目標(biāo)：持續(xù)打造和優(yōu)化一個能夠支持各交付團隊快速交付的平臺。

當(dāng)時，我們首先為團隊定義了新的工作方式：以自服務(wù)，自動化和協(xié)作作為核心文化，希望團隊通過提供便捷的基礎(chǔ)服務(wù)，讓交付團隊擁有自動化的交付流水線，并通過更多的溝通協(xié)作，盡可能讓每個交付團隊都能夠獨立自主的設(shè)計、創(chuàng)建和更改自己的基礎(chǔ)設(shè)施。然后再根據(jù)各個交付團隊的實施情況和結(jié)果來對流程和服務(wù)持續(xù)改進。

所以***件事，我們首先設(shè)計了一個高效的持續(xù)交付流水線，讓Platform團隊和交付團隊建立觸點：

如下圖所示，藍色的基因鏈為交付團隊的持續(xù)交付環(huán)，紅色的基因鏈為平臺團隊的持續(xù)交付環(huán)。兩種團隊以某種低耦合的弱連接進行全程協(xié)作，Platform團隊在整個端到端的交付過程中都要能盡量通過構(gòu)建自動化能力來支撐交付團隊能夠快速、安全的進行持續(xù)集成、部署等活動。這樣的合作方式也給我們提供了優(yōu)化觸點的可能性，也能夠通過優(yōu)化和改進，縮小這個持續(xù)交付周期，讓交付更高效。

請原諒我在這篇文章進入高潮時賣個關(guān)子，由于考慮到大家的閱讀體驗，所以文章分成了上、下兩個部分，上半部分主要講DevOps轉(zhuǎn)型的動機、策略和方法，下半部分會講我們?nèi)绾螌嶋H應(yīng)用基礎(chǔ)設(shè)施即代碼來建立Platform團隊和交付團隊的觸點，又怎樣讓遺留系統(tǒng)團隊和微服務(wù)團隊的交付速度成倍增加。敬請期待!

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文