DevOps轉(zhuǎn)型的動(dòng)機(jī)

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

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

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

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

我們將瓶頸具象化后(如上圖)，可以看到兩種團(tuán)隊(duì)之間其實(shí)是存在一堵墻的，一是因?yàn)閭鹘y(tǒng)的部署流程非常繁瑣和低效。二是因?yàn)閮煞N角色關(guān)注點(diǎn)和目標(biāo)的不一致。

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

那么引入DevOps文化，消除開發(fā)與運(yùn)維之間的壁壘，逐步打造更高效的交付流程就成為我們破局的關(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ā)展，強(qiáng)調(diào)IT自身對于市場的高適應(yīng)力。
2. 另外一種模式下，我們則需要穩(wěn)固發(fā)展，對于傳統(tǒng)模式我們傾向于更加嚴(yán)謹(jǐn)和標(biāo)準(zhǔn)的流程去保護(hù)現(xiàn)有業(yè)務(wù)，穩(wěn)定性比速度更加重要。

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

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

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

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

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

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

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

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

[[199655]]

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

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

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

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

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

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

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

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