建站
咨詢
售后
建站咨詢
新聞中心
DevOps轉(zhuǎn)型的動機(jī)
我們的客戶是一家海外本土***的金融保險集團(tuán)，他們在發(fā)展到一定規(guī)模以后，意識到自己就像一頭笨重的大象，舉步維艱，通過對整個交付流程的思考和分析，發(fā)現(xiàn)了以下一些嚴(yán)重影響交付速度的問題：
- 一些好的關(guān)于產(chǎn)品改善和創(chuàng)新的想法很難落地。涉及到一些遺留系統(tǒng)的配合：調(diào)整、部署、擴(kuò)展等，使團(tuán)隊對發(fā)布沒有信心。新的服務(wù)或者應(yīng)用的構(gòu)建，很難快速上線，被卡在了生產(chǎn)環(huán)境部署階段。
- 各種不同種類的應(yīng)用、服務(wù)的部署方式和流程不一致。運(yùn)維部門作為一個支持部門，很難為大量團(tuán)隊提供快速反應(yīng)。運(yùn)維人員對于需要部署和運(yùn)營環(huán)境之上的產(chǎn)品也不夠了解。
- 微服務(wù)運(yùn)營過程中，交付團(tuán)隊難以做到快速集成和部署。運(yùn)維團(tuán)隊對微服務(wù)的部署運(yùn)維方式不理解，依舊老瓶裝新藥，很難適配新架構(gòu)下的交付模式。開發(fā)團(tuán)隊大多關(guān)注代碼和架構(gòu)，對于產(chǎn)品如何能在生產(chǎn)環(huán)境穩(wěn)定運(yùn)行、需要考慮哪些安全性和可持續(xù)性的因素并不是很了解。
問題分析和挑戰(zhàn)
通過對這些問題和各個團(tuán)隊反饋的深入分析，發(fā)現(xiàn)其中***的瓶頸在于交付團(tuán)隊與運(yùn)維部門之間的各種依賴和溝通浪費(fèi)，而這個瓶頸又是解決大多數(shù)問題的前提。
我們將瓶頸具象化后(如上圖)，可以看到兩種團(tuán)隊之間其實是存在一堵墻的，一是因為傳統(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è)施，又如何去部署和運(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)，我們看看它是否能解決我們的問題：
先簡單介紹一下什么是雙模IT:
它將IT系統(tǒng)分成了兩種模式:
- 一種是新型的數(shù)字化、高市場適應(yīng)性的IT，這部分業(yè)務(wù)聚焦企業(yè)新市場和業(yè)務(wù)的開拓，創(chuàng)新和發(fā)展，強(qiáng)調(diào)IT自身對于市場的高適應(yīng)力。
- 另外一種模式下，我們則需要穩(wěn)固發(fā)展，對于傳統(tǒng)模式我們傾向于更加嚴(yán)謹(jǐn)和標(biāo)準(zhǔn)的流程去保護(hù)現(xiàn)有業(yè)務(wù)，穩(wěn)定性比速度更加重要。
我們從采用這樣一種模式的實踐案例中發(fā)現(xiàn)：組織內(nèi)部會出現(xiàn)連兩種速度的交付流程，好的情況可能是采用敏捷開發(fā)流程的交付線，有著快速的交付能力，相反，對于繼續(xù)采用傳統(tǒng)開發(fā)流程和運(yùn)維方式的團(tuán)隊，保持著穩(wěn)定但低效的交付能力。
從業(yè)界很多公司的現(xiàn)狀和發(fā)展趨勢來看，雙模IT確實是很多組織存在的現(xiàn)狀或是必然經(jīng)歷的過程，但不是一個好的模式，從實際的交付過程來看，存在4點問題：
- 雙模IT的劃分方式更多是基于軟件系統(tǒng)，而不是從業(yè)務(wù)活動出發(fā)進(jìn)行的，所有軟件系統(tǒng)的交付都應(yīng)該是面向業(yè)務(wù)價值的。
- 雙模IT會讓我們誤以為速度的提升會引起質(zhì)量的下降，但是對于我們在ThoughtWorks的很多敏捷實踐中學(xué)到的：隨著交付的推進(jìn)，質(zhì)量內(nèi)建是團(tuán)隊共同負(fù)責(zé)和持續(xù)改進(jìn)的重點。交付速度的提升，往往都伴隨著質(zhì)量的保障，而不是忽視質(zhì)量。
- 實際生產(chǎn)中，一個新的產(chǎn)品或者功能往往會依賴很多遺留系統(tǒng)提供的服務(wù)，如果它們僅僅只能達(dá)到穩(wěn)定和低效的交付，對企業(yè)來說對市場整體的響應(yīng)能力也會越來越低。
- 企業(yè)的創(chuàng)新不僅僅只是從零創(chuàng)造一個新的產(chǎn)品，還有很多機(jī)遇現(xiàn)有的資源。一個新的系統(tǒng)和功能往往不僅會既涉及到新服務(wù)、應(yīng)用的創(chuàng)建，也會涉及到遺留系統(tǒng)的修改，調(diào)整和改造。
由此可見雙模IT是在以一種試圖掩蓋問題的方式來逃避目前最重要的問題：開發(fā)和運(yùn)維之間的壁壘。感覺像是一個病人先是放棄治療，然后又努力的尋找延長壽命的方法，有些隱患終會爆發(fā)。
打造自服務(wù)持續(xù)交付
緊接著，我們開始采用了一種看似不可行的方式開啟了DevOps轉(zhuǎn)型，建立公有DevOps團(tuán)隊。有很多人可能會說這是一種反模式，怎么可能會建立一個團(tuán)隊專做DevOps相關(guān)的事情，那和以前的運(yùn)維部門又有什么區(qū)別?DevOps提倡的Dev與Ops高頻度合作的文化是不是就無法大面積傳播了?
因此我們需要很明確的定義我們對這個團(tuán)隊的期望和它的職責(zé)是什么，它是怎樣和交付團(tuán)隊合作，影響交付團(tuán)隊，最終能讓DevOps的文化可以大面積傳播。這個團(tuán)隊的目標(biāo)是要像杠桿一樣，翹起更大面積的DevOps變革。
所以我們認(rèn)為公有DevOps團(tuán)隊?wèi)?yīng)該與其它的端到端交付團(tuán)隊的人員構(gòu)成是一樣的。不同的只是目標(biāo)和價值，主要體現(xiàn)在幫助更多的團(tuán)隊植入DevOps文化、優(yōu)化持續(xù)交付流程。最終達(dá)到的目標(biāo)是每個團(tuán)隊都可以自治，每個團(tuán)隊都可以進(jìn)行端到端的開發(fā)、測試和部署，并可以自驅(qū)動的持續(xù)改進(jìn)。與此同時，這個團(tuán)隊不僅僅只是為交付團(tuán)隊提供更多涉及基礎(chǔ)設(shè)施、持續(xù)交付流水線、部署等活動所需要的自動化能力，還會支撐交付團(tuán)隊根據(jù)自身的上下文去定制和規(guī)劃自己的持續(xù)交付流程和部署策略等。
現(xiàn)在，相比于DevOps團(tuán)隊的叫法，我們更愿意稱呼這個團(tuán)隊為Platform團(tuán)隊，一個原因是我之前所說的避免被錯誤理解，另一個原因是隨著各個交付團(tuán)隊逐步實現(xiàn)自服務(wù)持續(xù)交付，這個專有團(tuán)隊也有了更高的目標(biāo)：持續(xù)打造和優(yōu)化一個能夠支持各交付團(tuán)隊快速交付的平臺。
當(dāng)時，我們首先為團(tuán)隊定義了新的工作方式：以自服務(wù)，自動化和協(xié)作作為核心文化，希望團(tuán)隊通過提供便捷的基礎(chǔ)服務(wù)，讓交付團(tuán)隊擁有自動化的交付流水線，并通過更多的溝通協(xié)作，盡可能讓每個交付團(tuán)隊都能夠獨立自主的設(shè)計、創(chuàng)建和更改自己的基礎(chǔ)設(shè)施。然后再根據(jù)各個交付團(tuán)隊的實施情況和結(jié)果來對流程和服務(wù)持續(xù)改進(jìn)。
所以***件事，我們首先設(shè)計了一個高效的持續(xù)交付流水線，讓Platform團(tuán)隊和交付團(tuán)隊建立觸點：
如下圖所示，藍(lán)色的基因鏈為交付團(tuán)隊的持續(xù)交付環(huán)，紅色的基因鏈為平臺團(tuán)隊的持續(xù)交付環(huán)。兩種團(tuán)隊以某種低耦合的弱連接進(jìn)行全程協(xié)作，Platform團(tuán)隊在整個端到端的交付過程中都要能盡量通過構(gòu)建自動化能力來支撐交付團(tuán)隊能夠快速、安全的進(jìn)行持續(xù)集成、部署等活動。這樣的合作方式也給我們提供了優(yōu)化觸點的可能性，也能夠通過優(yōu)化和改進(jìn)，縮小這個持續(xù)交付周期，讓交付更高效。
請原諒我在這篇文章進(jìn)入高潮時賣個關(guān)子，由于考慮到大家的閱讀體驗，所以文章分成了上、下兩個部分，上半部分主要講DevOps轉(zhuǎn)型的動機(jī)、策略和方法，下半部分會講我們?nèi)绾螌嶋H應(yīng)用基礎(chǔ)設(shè)施即代碼來建立Platform團(tuán)隊和交付團(tuán)隊的觸點，又怎樣讓遺留系統(tǒng)團(tuán)隊和微服務(wù)團(tuán)隊的交付速度成倍增加。敬請期待!
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
本文名稱：DevOps實踐——打造自服務(wù)持續(xù)交付（上）
文章分享：http://m.5511xx.com/article/djpjsoe.html
