《在復(fù)雜業(yè)務(wù)體系中DevOps理論及方法的實(shí)踐》要點(diǎn)：
本文介紹了在復(fù)雜業(yè)務(wù)體系中DevOps理論及方法的實(shí)踐，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

作者簡(jiǎn)介

胥峰
《Linux運(yùn)維最佳實(shí)踐》作者、《DevOps：軟件架構(gòu)師行動(dòng)指南》譯者
2006年畢業(yè)于南京大學(xué),2011年加入盛大游戲,十年運(yùn)維經(jīng)驗(yàn),曾參與盛大游戲多款大型端游和手游的上線運(yùn)維,主導(dǎo)統(tǒng)一運(yùn)維平臺(tái)的產(chǎn)品功能設(shè)計(jì)和實(shí)施,擁有工信部認(rèn)證高級(jí)信息系統(tǒng)項(xiàng)目管理師資格.《Linux運(yùn)維最佳實(shí)踐》作者、《DevOps：軟件架構(gòu)師行動(dòng)指南》譯者.

前言

本文來(lái)自于 GOPS 2017 深圳站的演講“在復(fù)雜業(yè)務(wù)體系中 DevOps 理論及方法的實(shí)踐”.分享分為 4 個(gè)方面：

• 初識(shí) DevOps；
• 建構(gòu)組織文化；
• 架構(gòu)技術(shù)體系；
• 案例研究；

1、初識(shí) DevOps

對(duì) DevOps 有這樣一個(gè)解釋：“ DevOps 是一套實(shí)踐方法,在保證高質(zhì)量的前提下,縮短從提交對(duì)系統(tǒng)的變更到部署到生產(chǎn)環(huán)境的時(shí)間”,這是引用了我翻譯的這本書(shū)里的概念.我們看一下這個(gè)概念里有哪些值得注意的關(guān)鍵點(diǎn)：

1. 我們?cè)诓渴鹣到y(tǒng)的時(shí)候,質(zhì)量是非常重要的.我們部署的系統(tǒng),你不能因?yàn)樽兏膯?wèn)題導(dǎo)致業(yè)務(wù)中斷,這是不可接受的問(wèn)題.
2. 要求交付機(jī)制也是高質(zhì)量的,就是你的交付過(guò)程.比如說(shuō)你交付到測(cè)試環(huán)境,交付到生產(chǎn)環(huán)境里面,也應(yīng)該是一個(gè)高質(zhì)量的.
3. 在里面規(guī)劃了兩個(gè)時(shí)間周期：一是開(kāi)發(fā)完成的時(shí)間；第二是把代碼開(kāi)發(fā)完成到部署到線上的時(shí)間.
4. 在這個(gè)定義里面強(qiáng)調(diào)了 DevOps 是一種以目標(biāo)作為導(dǎo)向的,它并沒(méi)有強(qiáng)調(diào)我們采取什么樣的形式的實(shí)踐,或者使用什么樣的工具.
5. 目標(biāo)并不限于 DevOps 用于測(cè)試和部署的實(shí)踐,它其實(shí)是把整個(gè)流程都包含在里面.

我們看到在 DevOps 的定義里面,最主要的一點(diǎn)還是講到從代碼開(kāi)發(fā)完成到上線的過(guò)程.這也是行業(yè)內(nèi)對(duì) DevOps 理解比較多的一點(diǎn).

這個(gè)圖來(lái)自企業(yè) DevOps 白皮書(shū),這是對(duì) DevOps 理解的一個(gè)擴(kuò)展.相對(duì)于前面說(shuō)的那個(gè)概念,它講到從開(kāi)發(fā)到部署的過(guò)程,但是在這個(gè)圖里我們可以看到,它其實(shí)是把流程進(jìn)行了前置和延伸.

比如說(shuō)計(jì)劃、需求、設(shè)計(jì),以及后面的運(yùn)維過(guò)程,它都把它納入到 DevOps 流程里面去了.這其實(shí)是講一個(gè)什么東西呢?一個(gè)產(chǎn)品或者一個(gè)業(yè)務(wù)有了想法之后,它就會(huì)進(jìn)行下面這樣的流程,從這個(gè)圖里面我們看到,它強(qiáng)調(diào)的是價(jià)值交付的過(guò)程.

從產(chǎn)品和業(yè)務(wù)來(lái)講,它開(kāi)始有些想法在里面,怎么通過(guò)技術(shù)手段、流程,快速的把這個(gè)想法變成一個(gè)產(chǎn)品,變成在實(shí)際場(chǎng)景中投放給客戶的產(chǎn)品,這是一個(gè)價(jià)值流的過(guò)程.

只有當(dāng)你的想法真正投入到里面去的時(shí)候,它才產(chǎn)生價(jià)值,你做的計(jì)劃也好,你做的開(kāi)發(fā)代碼也好,在沒(méi)有投放到生產(chǎn)之前,其實(shí)對(duì)用戶來(lái)講是沒(méi)有任何意義的.

上面這部分主要是講這個(gè)流程,在下面我們可以看到,其實(shí)它核心的理論支撐是精益和豐田生產(chǎn)系統(tǒng).我們?cè)谡麄€(gè)流程中需要非常關(guān)注的一點(diǎn)就是持續(xù)改進(jìn)的過(guò)程,不管我們現(xiàn)在的流程是什么樣的,或者說(shuō)你已經(jīng)做到什么地步了,其實(shí)都是有一些可以改進(jìn)的方向,包括這個(gè)精益也是告訴我們要持續(xù)不斷地做一些改進(jìn).

2、建構(gòu)組織文化

在這里面我想強(qiáng)調(diào)一點(diǎn),不管 DevOps 的定義是什么,它都是一個(gè)價(jià)值流的交付.從產(chǎn)品或者是業(yè)務(wù)的想法開(kāi)始,把它快速地、高質(zhì)量的交付給用戶.但是在實(shí)現(xiàn) DevOps 的過(guò)程中,很重要的一點(diǎn)是文化.不管組織的類型是什么,大部分組織都是懼怕變化的,所以采用 DevOps 這個(gè)新方法論可能是極具挑戰(zhàn)的.

在構(gòu)建組織文化的過(guò)程中,需要關(guān)注三個(gè)主要的原則：溝通、協(xié)作、集成.在這里面要強(qiáng)調(diào)一點(diǎn),我們現(xiàn)在各個(gè)部門在協(xié)作過(guò)程中,可能還存在一些部門利益沖突的問(wèn)題,這也是一個(gè)很現(xiàn)實(shí)的問(wèn)題.

另外一個(gè)就是我們要倡導(dǎo)一種免責(zé)文化,大家都說(shuō)運(yùn)維背黑鍋,這個(gè)其實(shí)是不對(duì)的,關(guān)鍵的一點(diǎn)是我們是以價(jià)值流交付作為一個(gè)整體的目標(biāo),倡導(dǎo)一種對(duì)事不對(duì)人的工作態(tài)度.

我們?cè)跇?gòu)建組織文化過(guò)程中要注意四個(gè)方面：

第一是團(tuán)隊(duì)內(nèi)的協(xié)作；

第二是團(tuán)隊(duì)之間的親和性；

第三是要使用一定的工具來(lái)加速流程的落地；

第四是伸縮性,隨著組織規(guī)模的擴(kuò)大, DevOps 流程也要做相應(yīng)的變化,

大家想想在我們的組織內(nèi)部,是不是有這樣的一些問(wèn)題,我們?cè)趥鹘y(tǒng)的開(kāi)發(fā)、測(cè)試、運(yùn)維過(guò)程中是什么樣的情況?開(kāi)發(fā)把代碼丟給測(cè)試去測(cè),測(cè)試測(cè)好之后,又把這個(gè)包丟給運(yùn)維部署到現(xiàn)場(chǎng),中間可能有相關(guān)的文檔,這本身就是一種筒倉(cāng)思維的表現(xiàn).

筒倉(cāng)思維的英文叫 Silo,它就像是在沙漠里面,或者是大型的場(chǎng)地里面有這樣一個(gè)個(gè)存儲(chǔ)物品的倉(cāng)庫(kù),每一個(gè)都是獨(dú)立、封閉的個(gè)體,它們之間是沒(méi)有溝通的,它們的利益也都是有沖突的.

這里講一個(gè)小故事,我們?cè)瓉?lái)有一個(gè)同事是來(lái)自國(guó)企的,他是做財(cái)務(wù)的.有一天他跟他的領(lǐng)導(dǎo)說(shuō),我們現(xiàn)在很多的工作還是手動(dòng)的,我們是不是可以引入一些自動(dòng)化的計(jì)算機(jī)系統(tǒng)來(lái)做這些事情?領(lǐng)導(dǎo)就問(wèn)他,這樣做有什么好處呢?他說(shuō),我們可以節(jié)省很多人力.

領(lǐng)導(dǎo)說(shuō),節(jié)省人力不行,你節(jié)省人力了,我這事就沒(méi)有人管了.大家有沒(méi)有理解這個(gè)意思?就是說(shuō)在體制內(nèi),領(lǐng)導(dǎo)比較關(guān)注他的權(quán)力的分配,而不是說(shuō)從整體角度提高工作效率.

還有一個(gè)與之類似的例子,在上海有一家基金公司,我有個(gè)同事去那里應(yīng)聘,當(dāng)然級(jí)別也比較高,他發(fā)現(xiàn)他們?cè)诓渴鸬臅r(shí)候還是手工去部署的,有幾個(gè)同事專門做部署的工作.

他就想去推動(dòng)這些自動(dòng)化部署的工具,但是他的領(lǐng)導(dǎo)說(shuō),我們還是要手工去布,這樣的話領(lǐng)導(dǎo)才會(huì)重視我這一塊,你全自動(dòng)化了,把我隱藏起來(lái)了,我這個(gè)經(jīng)理就沒(méi)用了,這就是很明顯的筒倉(cāng)思維.

包括我們?cè)谶\(yùn)營(yíng)一些產(chǎn)品或者業(yè)務(wù)的時(shí)候會(huì)發(fā)現(xiàn),開(kāi)發(fā)和運(yùn)維之間互相踢皮球的事情,這也是一種筒倉(cāng)思維.比如說(shuō)開(kāi)發(fā)肯定是要求快速上線,而運(yùn)維要求穩(wěn)定,大家的利益產(chǎn)生了沖突,這必然會(huì)對(duì)我們的價(jià)值流產(chǎn)生負(fù)面的作用.大家可以想想我們生活中或者是在工作里面是否也有這樣的筒倉(cāng)思維的表現(xiàn).

我們?cè)跇?gòu)建 DevOps 的過(guò)程中,必須要打破這種筒倉(cāng),形成合力,讓大家圍繞價(jià)值流一致的目的共同努力.

3、架構(gòu)技術(shù)體系

在構(gòu)建組織文化過(guò)程中有三點(diǎn)：溝通、協(xié)作、集成.集成肯定是一種自動(dòng)化集成,而不是說(shuō)手工對(duì)接的過(guò)程.這就要求我們?cè)陂_(kāi)發(fā)、測(cè)試和運(yùn)維整個(gè)鏈條里面,在每個(gè)環(huán)節(jié)上要能實(shí)現(xiàn)一定程度的自動(dòng)化,不能說(shuō)沒(méi)有對(duì)應(yīng)的運(yùn)維自動(dòng)化系統(tǒng)來(lái)對(duì)接前面的需求,完全是通過(guò)公開(kāi)的形式去做發(fā)布、部署,其實(shí)是不符合快速交付這樣一個(gè)理念的.

關(guān)于自動(dòng)化運(yùn)維這一塊,我可以簡(jiǎn)單說(shuō)一下我們盛大游戲是怎么做的.大家知道盛大游戲目前是國(guó)內(nèi)比較領(lǐng)先的游戲發(fā)行公司,它創(chuàng)立的時(shí)間比較早,在1999年這個(gè)公司就成立了,到目前已經(jīng)有18年的歷史.

它現(xiàn)在面臨的問(wèn)題,在運(yùn)營(yíng)方面主要表現(xiàn)為幾個(gè)：一是服務(wù)器操作系統(tǒng)異構(gòu)；另外一個(gè)是我們的服務(wù)器數(shù)量特別多,在高峰期的時(shí)候,我們的服務(wù)器達(dá)到2萬(wàn)臺(tái)的規(guī)模.

因?yàn)槊恳粋€(gè)游戲代理過(guò)來(lái)的時(shí)候,游戲的開(kāi)發(fā)商(比如說(shuō)美國(guó)、韓國(guó)、日本)服務(wù)器的偏好不一樣,面對(duì)這樣的挑戰(zhàn),我們?cè)趯?shí)現(xiàn)自動(dòng)化集成的過(guò)程中,我們是怎么構(gòu)建自動(dòng)化運(yùn)維平臺(tái)的呢?

從這個(gè)圖可以看到,我們有一臺(tái)中央控制機(jī)器,它從 CMDB 里面讀寫(xiě)數(shù)據(jù),根據(jù)不同的服務(wù)器的類型和操作內(nèi)容,把這個(gè)命令分發(fā)到對(duì)應(yīng)的服務(wù)器上面去.

我們可以看一下這里面的幾個(gè)特點(diǎn)：

第一,我們這個(gè)平臺(tái)是采用 BS 架構(gòu)的,不需要在電腦上裝軟件,現(xiàn)在在家里都可以操作,完成這個(gè)運(yùn)維任務(wù)；

第二,我們使用的是通用的協(xié)議來(lái)管理著所有的異構(gòu)系統(tǒng),比如說(shuō)我們?cè)?windows 下面,大家知道以前管理 windows 是比較困難的,現(xiàn)在有很多公司在這一塊也是依靠手工去操作的,這樣會(huì)很麻煩,也有可能造成一些遺漏或者是錯(cuò)誤的過(guò)程.

對(duì)于 windows 管理,我們也是采用了 SSH 的方法去做,這樣就可以讓所有服務(wù)器以相同的方式管理起來(lái),比如說(shuō)它們的安全策略,公鑰和私鑰的管理,另外還有一些審計(jì),都可以內(nèi)置在這個(gè)操作平臺(tái)里面.

關(guān)于自動(dòng)化運(yùn)維平臺(tái)這一塊,還要注意做一些并發(fā)的設(shè)置,以及超時(shí)和重試的機(jī)制,都需要考慮到里面去,不能因?yàn)橐恍╉樞虻膱?zhí)行,某臺(tái)服務(wù)器的故障,或者是連接服務(wù)器的問(wèn)題,導(dǎo)致它無(wú)法連接,導(dǎo)致整個(gè)任務(wù)延遲.

現(xiàn)在我們?cè)谧隽硗庖粋€(gè)系統(tǒng)是作業(yè)編排系統(tǒng),如果知道 Ansible ?playbooks 的話,可以看一下它的方式和方法.我們知道 playbooks 是通過(guò)聲明一些配置項(xiàng),然后把它編排起來(lái),把所有的人工分類的步驟做進(jìn)一個(gè)配置里面,讓它順序執(zhí)行.

比如說(shuō)我們做游戲維護(hù)的時(shí)候：

第一步,是先把服務(wù)器上的游戲服停掉；

第二步,停數(shù)據(jù)庫(kù)；

第三步,更新程序；

第四步,還要更新數(shù)據(jù)庫(kù)的一些表結(jié)構(gòu)；

第五步,把前面的游戲服務(wù)器啟動(dòng)起來(lái),或者數(shù)據(jù)庫(kù)啟動(dòng)起來(lái)；

通過(guò)一些作業(yè)編排,就能更大地減少這個(gè)運(yùn)維的重復(fù)勞動(dòng)的過(guò)程,它的理念其實(shí)是基于場(chǎng)景的自動(dòng)化運(yùn)維.我們可以想想在運(yùn)維過(guò)程中有哪些工作可以串聯(lián)起來(lái),這樣你就不需要對(duì)著一個(gè)文本的東西去做,因?yàn)槟阍趯?duì)著它做的過(guò)程中很容易造成遺漏.

比如說(shuō)你做游戲維護(hù)的時(shí)候,沒(méi)有把前面的關(guān)閉,你就直接維護(hù)數(shù)據(jù)庫(kù)了,這時(shí)候可能會(huì)導(dǎo)致玩家數(shù)據(jù)丟失的情況.通過(guò) playbook 編排系統(tǒng),就可以避免這個(gè)事情,它是固化的,沒(méi)有辦法繞過(guò)前面的步驟去進(jìn)行后面的操作.

4、案例研究

剛剛說(shuō)過(guò),大家在不同的行業(yè)里面,在不同的業(yè)務(wù)里面,它對(duì)應(yīng)的發(fā)布方式還不一樣,我相信目前我們?cè)谧?系統(tǒng)里面也有一些人是用手工發(fā)布的方法上線.我知道一個(gè)比較大的公司,它的部署也是很落后的方式,因?yàn)樗懊嬗胸?fù)載均衡,它布的時(shí)候還是要登一些腳本,把負(fù)載均衡上的東西剔除,然后再更新,它需要更新多個(gè)腳本,這是很浪費(fèi)時(shí)間和精力的過(guò)程.

 

看看我們以前面臨的問(wèn)題.這是我們的某個(gè)平臺(tái),主要是支付相關(guān)的.大家知道我們除了游戲服務(wù)器之外,還有相關(guān)的登錄、認(rèn)證和計(jì)費(fèi)的平臺(tái).我們第一個(gè)選取的案例是在支付平臺(tái)這邊做的一些 DevOps 實(shí)踐.

隨著公司業(yè)務(wù)的發(fā)展,日積月累,你這個(gè)模塊可能會(huì)越來(lái)越多,部署了之后會(huì)有測(cè)試,測(cè)試了之后交給運(yùn)維,但是測(cè)試的模塊名和運(yùn)維的模塊名可能是不一樣的,這里面存在一個(gè)協(xié)調(diào)的問(wèn)題.因?yàn)橛腥斯f(xié)調(diào)的過(guò)程,不然導(dǎo)致這個(gè)部署需要排期,原來(lái)部署和測(cè)試系統(tǒng)是割裂的,它們之間沒(méi)有對(duì)應(yīng)的關(guān)系.

?

我們是怎么改進(jìn)的呢?現(xiàn)在已經(jīng)做的工作是：

• 第一,我們建立在部署流水線上不同環(huán)節(jié)的模塊對(duì)應(yīng)關(guān)系,首先把它映射好.比如說(shuō)測(cè)試和運(yùn)維這邊的部署系統(tǒng),它們之間的對(duì)應(yīng)關(guān)系要映射到數(shù)據(jù)庫(kù)里面去,這樣就可以實(shí)現(xiàn)從前端出發(fā)的部署動(dòng)作.
• 第二,后端的部署系統(tǒng),它需要提供對(duì)應(yīng)的功能接口.比如說(shuō)它需要上游的系統(tǒng)提供一個(gè)模塊對(duì)應(yīng)哪些服務(wù)器的接口,當(dāng)上游需要部署某個(gè)模塊的時(shí)候,它就知道在測(cè)試環(huán)境里面需要部署哪些服務(wù)器,在正式環(huán)境,灰度發(fā)布的時(shí)候需要先部署哪些,再部署哪些.
• 第三,建立對(duì)應(yīng)的授權(quán)機(jī)制,我們可以把部分模塊的授權(quán)前置給開(kāi)發(fā)上線,或者是由運(yùn)維從內(nèi)部平臺(tái)直接部署上線,取得的效果是非常明顯的.在2016年12月份的時(shí)候我們做了一個(gè)統(tǒng)計(jì),當(dāng)時(shí)有900多次的部署,其中50%以上通過(guò)新平臺(tái)自動(dòng)部署,大約10%的模塊可以由開(kāi)發(fā)自主上線,不涉及到核心功能的,開(kāi)發(fā)簡(jiǎn)單測(cè)試一下就直接上去了.非核心模塊的部署,我們可以在5分鐘內(nèi)完成,不再需要一些配置管理員進(jìn)行上線的排期和編排.

這是我們部署的系統(tǒng)的界面,它會(huì)選擇對(duì)應(yīng)的版本,選擇你是灰度發(fā)布,還是部署到生產(chǎn)環(huán)節(jié)里面,這個(gè)動(dòng)作很多情況下已經(jīng)不需要運(yùn)維去做了,直接測(cè)試完成之后就可以上線了,這時(shí)候就把運(yùn)維的工作解放出來(lái)了.

這是我們的部署過(guò)程,對(duì)于自動(dòng)部署,銀行和金融機(jī)構(gòu)有要求,開(kāi)發(fā)和運(yùn)維要分離,我們現(xiàn)在做的是讓開(kāi)發(fā)和測(cè)試都可以上線.

我們的底層部署是通過(guò)配置一些項(xiàng)目,比如說(shuō)模塊對(duì)應(yīng)的目錄、配置文件、執(zhí)行腳本,對(duì)應(yīng)的用戶,這個(gè)用戶主要是指啟動(dòng)程序時(shí)的用戶,以及對(duì)應(yīng)的某個(gè)模塊在不同的服務(wù)器上的IP列表,這些都會(huì)在系統(tǒng)里面進(jìn)行相關(guān)的配置,這樣配置之后就可以對(duì)前面的系統(tǒng)進(jìn)行相關(guān)調(diào)用.

這個(gè)案例也告訴我們一點(diǎn),我們?cè)谶M(jìn)行部署設(shè)計(jì)的時(shí)候,暗含了對(duì)架構(gòu)的要求.

這里簡(jiǎn)單介紹三點(diǎn)：

• 第一,模塊化,可獨(dú)立部署,微服務(wù)有一個(gè)類似的概念.如果你是一個(gè)大一統(tǒng)的體系,你很難集中發(fā)布這個(gè)東西,你還要協(xié)調(diào)很多資源,如果你做成模塊化,你自己上線,不影響他人,通過(guò)接口去調(diào)用,對(duì)自動(dòng)部署是非常有好處的；
• 第二,重試機(jī)制.作為一些后端的服務(wù),它在部署的時(shí)候,不應(yīng)該影響前端的調(diào)用服務(wù),前端的調(diào)用服務(wù)必須有一些重試機(jī)制,失敗的時(shí)候要能夠重連,這應(yīng)該集成在調(diào)用方的架構(gòu)設(shè)計(jì)里面,如果沒(méi)有重試機(jī)制,肯定是會(huì)影響業(yè)務(wù)的,這也沒(méi)辦法達(dá)到高質(zhì)量交付的目的；
• 第三,負(fù)載均衡與多實(shí)例的應(yīng)用.這里也講到,如果你的某一個(gè)功能只有一個(gè)模塊,你在部署的時(shí)候,不管它的時(shí)間窗口是什么,你必然會(huì)影響業(yè)務(wù),有些請(qǐng)求會(huì)丟掉或者是失敗.通過(guò)負(fù)載均衡和多實(shí)例的方法,就可以包括你在部署部分服務(wù)器的時(shí)候不影響前面調(diào)用的結(jié)果.

總結(jié)

DevOps 的目的是打造持續(xù)增量的價(jià)值流并杜絕浪費(fèi).我曾經(jīng)有一句話「任何不以消除浪費(fèi)為目的的 DevOps 實(shí)踐都是假的 DevOps」,我們實(shí)踐 DevOps 的目的,是實(shí)現(xiàn)從一個(gè)想法到真正把這個(gè)想法形成產(chǎn)品、形成服務(wù),提供給用戶去用的流程.

縮短這個(gè)過(guò)程的時(shí)間,提高這個(gè)過(guò)程的效率是 DevOps 實(shí)踐的一個(gè)最重要的目的.我們要讓每一個(gè)步驟,每一個(gè)過(guò)程的價(jià)值都是遞增的,而不是說(shuō)產(chǎn)生等待,或者說(shuō)產(chǎn)生依賴,比如對(duì)配置管理的依賴,對(duì)人員的依賴,這都是有悖于這個(gè)目的的.

所以我把這句話送給大家：DevOps 的目的,最重要的一點(diǎn)就是加速高質(zhì)量的交付,提升用戶價(jià)值.但是在實(shí)踐過(guò)程中,我們可以從各個(gè)子環(huán)節(jié)的自動(dòng)化流程作為一個(gè)起點(diǎn),很多時(shí)候你可能沒(méi)辦法一次性把整個(gè)部署流水線構(gòu)建那么完美,我們就可以分析是不是在每個(gè)子環(huán)節(jié)里面已經(jīng)實(shí)現(xiàn)了足夠程度的自動(dòng)化.

比如說(shuō)自動(dòng)化發(fā)布,現(xiàn)在是不是還是要靠人工去操作,這些是最基本的動(dòng)作,做好這些之后,你才有能力或者有條件和上下游進(jìn)行對(duì)接.只有完成的每個(gè)環(huán)節(jié)的自動(dòng)化之后,我們才有可能去構(gòu)建整個(gè)部署流水線.

也就是說(shuō)我們?cè)诼涞氐臅r(shí)候可以想想整個(gè)業(yè)務(wù)流程里面的痛點(diǎn),比如說(shuō)你是部署沒(méi)有完成自動(dòng)化,還是測(cè)試沒(méi)有完成自動(dòng)化,導(dǎo)致了這個(gè)流水線沒(méi)有辦法流傳下去.然后以每個(gè)環(huán)節(jié)的自動(dòng)化作為一個(gè)開(kāi)始,然后把它們集成起來(lái),就可以實(shí)現(xiàn)整個(gè)價(jià)值流的快速交付.

文章來(lái)自微信公眾號(hào)：高效運(yùn)維

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.snjht.com/jiaocheng/2724.html