建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
- - DevOps原則所追求的愿景，就是“讓業(yè)務(wù)所要求的那些變化能隨時(shí)上線(xiàn)可用”;
- - DevOps的起源表明，其原則是從Agile與Lean的實(shí)踐當(dāng)中提煉而來(lái)，因此與Agile和Lean的原則并無(wú)二致;
- - 本文所討論的DevOps原則可以用“人、產(chǎn)品、流程和工具”這4個(gè)維度來(lái)進(jìn)行組織。
“你在做用戶(hù)故事拆分?這不是在做DevOps?！边@是筆者在2016年以咨詢(xún)師的身份，參與一家大型跨國(guó)金融企業(yè)的Agile和DevOps轉(zhuǎn)型時(shí)所聽(tīng)到的話(huà)。在這家企業(yè)，Agile和DevOps明顯指的是不同的東西：前者專(zhuān)指每日站會(huì)、計(jì)劃會(huì)、回顧會(huì)等Scrum的實(shí)踐和用戶(hù)故事實(shí)踐;后者專(zhuān)指自動(dòng)化、工具鏈和基礎(chǔ)設(shè)施等實(shí)踐。
成都創(chuàng)新互聯(lián)是一家成都網(wǎng)站建設(shè)、成都做網(wǎng)站，提供網(wǎng)頁(yè)設(shè)計(jì)，網(wǎng)站設(shè)計(jì)，網(wǎng)站制作，建網(wǎng)站，按需策劃，網(wǎng)站開(kāi)發(fā)公司，2013年開(kāi)創(chuàng)至今是互聯(lián)行業(yè)建設(shè)者，服務(wù)者。以提升客戶(hù)品牌價(jià)值為核心業(yè)務(wù)，全程參與項(xiàng)目的網(wǎng)站策劃設(shè)計(jì)制作，前端開(kāi)發(fā)，后臺(tái)程序制作以及后期項(xiàng)目運(yùn)營(yíng)并提出專(zhuān)業(yè)建議和思路。
過(guò)了一段時(shí)間，筆者把本文所列舉的一些DevOps原則發(fā)到一個(gè)相關(guān)微信群里面，得到了這樣的反饋：“怎么滿(mǎn)眼都是敏捷和精益?”“感覺(jué)DevOps被一群不操作Op的人給玩兒壞了?！?/p>
這些經(jīng)歷讓筆者開(kāi)始關(guān)心這些問(wèn)題：既然Dev指的是“開(kāi)發(fā)”，Ops指的是“運(yùn)維”，那么到底什么是DevOps?它的原則是什么?它和敏捷、精益的關(guān)系是什么?讓我們先觀(guān)察一下DevOps的起源。
一、DevOps的起源可以分為兩條線(xiàn)
第一條線(xiàn)是:比利時(shí)獨(dú)立咨詢(xún)師Patrick Debois
2007年他在比利以咨詢(xún)師的身份，參與了一個(gè)政府?dāng)?shù)據(jù)中心遷移中的測(cè)試工作。他在做測(cè)試時(shí)，需要頻繁往返于Dev團(tuán)隊(duì)和Ops團(tuán)隊(duì)之間。Dev團(tuán)隊(duì)已經(jīng)實(shí)踐了敏捷，而Ops團(tuán)隊(duì)還是傳統(tǒng)運(yùn)維的工作方式。看到Ops團(tuán)隊(duì)每天忙于救火和疲于奔命的狀態(tài)，他在想：能否把敏捷的實(shí)踐引入Ops團(tuán)隊(duì)呢?
第二條線(xiàn)是:當(dāng)時(shí)雅虎旗下的圖片分享網(wǎng)站Flickr
這家公司的運(yùn)維部門(mén)經(jīng)理John Allspaw和工程師Paul Hammond，于2009年6月23日在美國(guó)圣荷西舉辦的Velocity 2009大會(huì)上，發(fā)表了一個(gè)引燃DevOps的演講。這個(gè)演講的題目在當(dāng)時(shí)很搶眼--《每天部署10次以上：Flickr公司的Dev與Ops的合作》這個(gè)演講有一個(gè)核心議題：Dev和Ops的目標(biāo)到底是不是沖突?傳統(tǒng)觀(guān)念認(rèn)為Dev和Ops的目標(biāo)是有沖突的——Dev的工作是添加新特性，而Ops的工作是保持系統(tǒng)運(yùn)行的穩(wěn)定和快速;而Dev在添加新特性時(shí)所帶來(lái)的代碼變化，會(huì)導(dǎo)致系統(tǒng)運(yùn)行不穩(wěn)定和變慢，從而引發(fā)Dev與Ops的沖突。
然而從全局來(lái)看，Dev和Ops的目標(biāo)是一致的，即都是“讓業(yè)務(wù)所要求的那些變化能隨時(shí)上線(xiàn)可用”。
這樣搶眼的題目和鮮明的觀(guān)點(diǎn)，自然抓住了當(dāng)時(shí)還在比利時(shí)的Debois。他在“推特”上發(fā)帖：“可惜沒(méi)法去現(xiàn)場(chǎng)參加?！迸笥裀aul Nasrat回帖說(shuō)：“為什么不在比利時(shí)搞一個(gè)你自己的Velocity大會(huì)?”這兩條線(xiàn)使得Debois擼起袖子，于2009年10月30至31日，在比利時(shí)的第二大城市根特，以社區(qū)自發(fā)的形式舉辦了一個(gè)名為DevOpsDays的大會(huì)。
這次大會(huì)吸引了不少開(kāi)發(fā)者、系統(tǒng)管理員和軟件工具程序員。這兩天大家聊得太開(kāi)心了，會(huì)議結(jié)束還不過(guò)癮，回去繼續(xù)在“推特”上聊。限于推特140個(gè)字符的制約，Debois把DevOpsDays中的Days去掉，而創(chuàng)建了#DevOps#這個(gè)“推特”聊天主題標(biāo)簽，DevOps誕生了。
二、DevOps的愿景
Flickr公司的兩位演講者所表達(dá)的“Dev和Ops的共同目標(biāo)是讓業(yè)務(wù)所要求的那些變化能隨時(shí)上線(xiàn)可用”這一觀(guān)點(diǎn)，其實(shí)就是DevOps的愿景。而要達(dá)到這一點(diǎn)，可以使用一個(gè)現(xiàn)成的工具：精益。源自豐田生產(chǎn)方式的“精益”的愿景就是“Shortest lead time”，即用最短的時(shí)間來(lái)完成從客戶(hù)下訂單到收到貨物的全過(guò)程。這恰好能幫助實(shí)現(xiàn)DevOps的上述愿景。
《持續(xù)交付》的作者之一Jez Humble也體會(huì)出精益在DevOps中的重要性，以至于他把DevOps的CAMS框架修訂為CALMS，其中增加的L指的就是Lean(精益)，這一點(diǎn)下文還會(huì)提及。
從上面DevOps的起源中能夠看出三點(diǎn)：
- DevOps源自草根社區(qū)，最初并沒(méi)有什么自上而下設(shè)計(jì)出來(lái)的理論框架;
- DevOps背后的原則，就是上面兩條線(xiàn)中所涉及的敏捷和精益的原則;
- DevOps的愿景是讓業(yè)務(wù)所要求的那些變化能隨時(shí)上線(xiàn)可用。
一旦了解了上面第二點(diǎn)，就不會(huì)有前文中所說(shuō)的“Agile和DevOps是不同的東西”和“感覺(jué)DevOps被一群不操作Op的人給玩兒壞了”這樣的說(shuō)法。
因?yàn)镈evOps源自草根，沒(méi)有什么框架，所以如何定義DevOps成了DevOps社區(qū)里面的一個(gè)大難題。一些DevOps從業(yè)者，紛紛設(shè)定自己的DevOps框架。其中比較有名的框架有上文提到的Damon Edwards所定義并被Jez Humble所修訂的CALMS，和Gene Kim所定義的The Three Ways。
CALMS:
- Culture – 文化：公司各個(gè)角色一起擔(dān)當(dāng)業(yè)務(wù)變化，實(shí)現(xiàn)有效協(xié)作和溝通;
- Automation – 自動(dòng)化：在價(jià)值鏈中盡量除去手工步驟;
- Lean – 精益：運(yùn)用精益原則更頻繁地交付價(jià)值;
- Metrics – 度量：度量并使用數(shù)據(jù)來(lái)優(yōu)化交付周期;
- Sharing – 分享：分享成功和失敗的經(jīng)驗(yàn)來(lái)相互學(xué)習(xí)。
The Three Ways:
- The First Way：System Thinking (系統(tǒng)思考：強(qiáng)調(diào)全局優(yōu)化，避免局部?jī)?yōu)化);
- The Second Way：Amplify Feedback Loops (經(jīng)過(guò)放大的反饋回路：創(chuàng)建從開(kāi)發(fā)過(guò)程下游至上游的反饋環(huán));
- The Third Way：Culture of Continual Experimentation And Learning(持續(xù)做試驗(yàn)和學(xué)習(xí)的文化：持續(xù)做試驗(yàn)，承擔(dān)風(fēng)險(xiǎn)、從失敗中學(xué)習(xí);通過(guò)反復(fù)實(shí)踐來(lái)達(dá)到精通)。
(圖片來(lái)自：http://t.cn/RijRjYS)
三、DevOps的原則
本文試著從“人、產(chǎn)品、流程和工具”4個(gè)維度，來(lái)梳理DevOps的一些原則。為什么會(huì)有這4個(gè)維度?
先看前三個(gè)維度：“人”、“產(chǎn)品”和“流程”。在一百多年前的工業(yè)經(jīng)濟(jì)時(shí)代，由于物質(zhì)匱乏，所以當(dāng)時(shí)占主導(dǎo)地位的泰勒科學(xué)管理理論將“流程”這個(gè)維度放到了第一位，讓企業(yè)首先通過(guò)標(biāo)準(zhǔn)化的“流程”達(dá)到規(guī)模化的制造能力，來(lái)滿(mǎn)足供不應(yīng)求的市場(chǎng)。
市場(chǎng)上可購(gòu)買(mǎi)的商品少，人們對(duì)“產(chǎn)品”的質(zhì)量、設(shè)計(jì)也就不介意了，所以“產(chǎn)品”排在了第二位。而標(biāo)準(zhǔn)化的流程把工人的素質(zhì)標(biāo)準(zhǔn)降到了最低，只要帶著一雙手來(lái)，在流水線(xiàn)上重復(fù)一個(gè)動(dòng)作就好了，不需要?jiǎng)幽X子，因此“人”排在了最后的位置。
一百年后，工業(yè)經(jīng)濟(jì)霸主的地位已被知識(shí)經(jīng)濟(jì)所取代。在具有知識(shí)密集特點(diǎn)的敏捷軟件開(kāi)發(fā)的上下文中，這三個(gè)維度的順序顛倒了：“人”的優(yōu)先級(jí)最高，因?yàn)橹挥幸揽俊叭恕钡膭?chuàng)造力才能應(yīng)對(duì)多變的業(yè)務(wù)需求;給用戶(hù)提供價(jià)值的“產(chǎn)品”依舊排第二位，因?yàn)檫@是企業(yè)賴(lài)以生存的根基;而“流程”可以為了“人”來(lái)高效地實(shí)現(xiàn)“產(chǎn)品”而進(jìn)行定制，所以?xún)?yōu)先級(jí)最低。而強(qiáng)調(diào)自動(dòng)化的DevOps離不開(kāi)好用的“工具”，“工具”又可以依據(jù)流程來(lái)定制，因而可以補(bǔ)在“流程”的后面。
(圖片來(lái)自：http://t.cn/RijRMrp)
下面所描述的DevOps原則，來(lái)源于敏捷、精益和DevOps的一些具體實(shí)踐。雖然沒(méi)有涵蓋DevOps的所有實(shí)踐，但已經(jīng)包括筆者最近一年在DevOps的實(shí)踐中所感悟的主要內(nèi)容，而且今后會(huì)繼續(xù)完善。
一般的文章對(duì)于“原則”的闡述都比較抽象，有點(diǎn)像上面提到的CALMS和The Three Ways這兩個(gè)框架的定義方式那樣——僅僅把幾個(gè)名詞或短語(yǔ)放到那里。對(duì)于不熟悉Agile、Lean和DevOps的人來(lái)說(shuō)，看了上述框架還是不知道DevOps到底是做啥的。
為了讓DevOps原則的描述更加具體生動(dòng)，筆者參考敏捷宣言的寫(xiě)法和實(shí)例化需求的做法(即用具體的實(shí)際例子來(lái)編寫(xiě)驗(yàn)收條件)，使用了“高于”和“而非”的句式來(lái)對(duì)比兩個(gè)具體實(shí)踐的實(shí)例，且盡量用一些具體的實(shí)踐來(lái)代表相應(yīng)的原則，如“部署流水線(xiàn)”等。其中，“高于”表示右邊的實(shí)踐雖然不如左邊的好，但還是有價(jià)值的?！岸恰北硎居疫叺膶?shí)踐并不值得推薦。這就是本文標(biāo)題中“實(shí)例化”的由來(lái)。
1. 人
（1）領(lǐng)導(dǎo)者身體力行持續(xù)改進(jìn) 高于 關(guān)注工具和基礎(chǔ)設(shè)施
很多企業(yè)(包括筆者所輔導(dǎo)的企業(yè))都在實(shí)踐DevOps。要想讓DevOps這顆樹(shù)苗茁壯成長(zhǎng)，企業(yè)要為其提供一個(gè)良好的土壤——即企業(yè)文化。而企業(yè)文化，是企業(yè)領(lǐng)導(dǎo)者引導(dǎo)塑造的。
DevOps對(duì)于國(guó)內(nèi)大部分企業(yè)來(lái)說(shuō)，都是一個(gè)前所未有的新事物。必須通過(guò)不斷做試驗(yàn)，才能找到培育它生長(zhǎng)的土壤方，做試驗(yàn)就是為持續(xù)改進(jìn)做準(zhǔn)備。筆者所輔導(dǎo)的企業(yè)，工程師被項(xiàng)目進(jìn)度壓得喘不過(guò)氣來(lái)，根本沒(méi)有時(shí)間學(xué)習(xí)新工具和新方法，更別提做試驗(yàn)了。
(圖片來(lái)自：http://www.yes123.com.tw/)
所以只有領(lǐng)導(dǎo)者身體力行，不僅自己親自做試驗(yàn)和進(jìn)行持續(xù)改進(jìn)，并給工程師足夠的時(shí)間來(lái)做試驗(yàn)和持續(xù)改進(jìn)，這樣所創(chuàng)造出良好的環(huán)境，才能讓那些自動(dòng)化工具和基礎(chǔ)設(shè)施在企業(yè)內(nèi)部得到有效利用。
（2）試驗(yàn)并改進(jìn)流程 而非 指責(zé)人的過(guò)失
豐田公司有一句口號(hào)：“對(duì)流程苛，對(duì)人員柔”，意思是說(shuō)：每位員工都會(huì)盡力做好工作的，那些在工作中所出現(xiàn)的問(wèn)題都是流程的問(wèn)題。因?yàn)楦鶕?jù)這種有問(wèn)題的流程來(lái)工作，無(wú)論是誰(shuí)都會(huì)出同樣的問(wèn)題。
前面說(shuō)過(guò)，DevOps對(duì)于國(guó)內(nèi)大部分企業(yè)都是新事物，需要做試驗(yàn)來(lái)“摸著石頭過(guò)河”，做試驗(yàn)就有失敗的時(shí)候，此時(shí)就要調(diào)整流程，而不是怪罪于人，否則企業(yè)沒(méi)有人會(huì)去繼續(xù)嘗試DevOps。
（3）產(chǎn)品思維 高于 項(xiàng)目思維
根據(jù)這一個(gè)原則可以定義“人”的組織結(jié)構(gòu)——團(tuán)隊(duì)結(jié)構(gòu)，即可以按照產(chǎn)品而不是項(xiàng)目來(lái)組建團(tuán)隊(duì)。這樣的產(chǎn)品團(tuán)隊(duì)包括了Dev、Ops、BA、Tester、PO和Architect等各種角色，他們相互配合且不依靠團(tuán)隊(duì)以外的其他角色就能獨(dú)立自主地交付軟件產(chǎn)品，這個(gè)產(chǎn)品團(tuán)隊(duì)負(fù)責(zé)該產(chǎn)品從生到死的全生命周期，并且只要產(chǎn)品還在，這個(gè)團(tuán)隊(duì)就不會(huì)解散。
這種設(shè)置會(huì)讓團(tuán)隊(duì)的不同角色目標(biāo)一致，比起從目標(biāo)不一致的各種職能團(tuán)隊(duì)(比如Dev團(tuán)隊(duì)、Tester團(tuán)隊(duì)和BA團(tuán)隊(duì))抽調(diào)人員拼湊成臨時(shí)的項(xiàng)目團(tuán)隊(duì)，磨合期更短，更加有戰(zhàn)斗力。
2. 產(chǎn)品
（1）質(zhì)量和安全內(nèi)建 而非 晚期度量和檢查
產(chǎn)品需要質(zhì)量和安全來(lái)保證價(jià)值。人們長(zhǎng)期認(rèn)為“高質(zhì)量”意味著“高成本”，因?yàn)橐S護(hù)高質(zhì)量，需要在產(chǎn)品出廠(chǎng)前做大批量檢測(cè)，并銷(xiāo)毀那些次品，這就花費(fèi)了高昂的成本。但豐田公司卻說(shuō)“高質(zhì)量是免費(fèi)的”。這是怎么做到的呢?
這其實(shí)就是前文提到的豐田公司“對(duì)流程苛”的結(jié)果。豐田公司通過(guò)持續(xù)改進(jìn)流程，“一次就把事情做對(duì)”，這樣就能在脫離后期大規(guī)模檢查的情況下保證高質(zhì)量，同時(shí)其成本也趨近于零。
（2）客戶(hù)反饋 高于 按期交付
產(chǎn)品是否實(shí)現(xiàn)了價(jià)值，只有通過(guò)客戶(hù)的反饋才能知道。很多團(tuán)隊(duì)往往過(guò)分關(guān)注交付期限，而忽視客戶(hù)反饋。這樣做的后果，就是雖然按期交付，但是產(chǎn)品卻不是客戶(hù)所期望的，造成返工或項(xiàng)目失敗。
（3）基于不可變?nèi)萜鞯奈⒎?wù) 高于 單塊應(yīng)用
產(chǎn)品需要能快速地開(kāi)發(fā)、測(cè)試和部署才能有效地交付價(jià)值。對(duì)于復(fù)雜度高的大型產(chǎn)品，如果可以由多個(gè)微服務(wù)組合而成，每個(gè)微服務(wù)都能獨(dú)立地開(kāi)發(fā)、測(cè)試、部署和上線(xiàn)。這比起必須集成各個(gè)模塊才能進(jìn)行手工測(cè)試的單塊應(yīng)用來(lái)說(shuō)，更能實(shí)現(xiàn)各個(gè)微服務(wù)之間的并行研發(fā)，加快每個(gè)微服務(wù)的開(kāi)發(fā)下游至上游的反饋環(huán)的反饋速度，進(jìn)而縮短項(xiàng)目進(jìn)度，讓價(jià)值交付得更快。
不可變?nèi)萜髦傅氖擒浖a(chǎn)品被封裝到一個(gè)類(lèi)似docker這樣的容器內(nèi)上線(xiàn)，且上線(xiàn)后不可手工修改其配置。如果一定要修改，也只能通過(guò)部署流水線(xiàn)把要修改的內(nèi)容重新打包成另一個(gè)新的不可變?nèi)萜鱽?lái)上線(xiàn)。
這樣做的好處是能夠?qū)崿F(xiàn)部署和發(fā)布自動(dòng)化以及進(jìn)行更好的版本控制，消除線(xiàn)上手工配置所帶來(lái)的無(wú)法審計(jì)的風(fēng)險(xiǎn)。這一實(shí)踐是本文寫(xiě)作時(shí)期的推薦實(shí)踐，該實(shí)踐今后還會(huì)繼續(xù)演進(jìn)。
3. 流程
（1）管理層實(shí)踐Improvement Kata和Coaching Kata進(jìn)行流程持續(xù)改進(jìn) 高于 用結(jié)果導(dǎo)向進(jìn)行管理
佛家說(shuō)：“菩薩畏因，眾生畏果”。傳統(tǒng)按結(jié)果導(dǎo)向進(jìn)行管理的一個(gè)弊病，就是團(tuán)隊(duì)成員會(huì)把注意力放到結(jié)果上，而不是產(chǎn)生這樣結(jié)果的原因——即過(guò)程改進(jìn)之上。這樣的后果就是，大家會(huì)把精力放到如何讓報(bào)表好看，而不是真正地提高團(tuán)隊(duì)成員的持續(xù)改進(jìn)能力來(lái)真正達(dá)到所期望的結(jié)果。
企業(yè)管理層可以參考《豐田套路》一書(shū)來(lái)帶頭實(shí)踐Improvement Kata和Coaching Kata，讓企業(yè)產(chǎn)生持續(xù)改進(jìn)的文化。其中，Improvement Kata是通過(guò)一系列“確定目標(biāo)—>考察現(xiàn)狀—>識(shí)別困難—>制定方案—>觀(guān)察成效”的PDCA反饋環(huán)來(lái)做持續(xù)改進(jìn);Coaching Kata是通過(guò)導(dǎo)師“一對(duì)一帶學(xué)徒”的方式來(lái)讓企業(yè)全員掌握持續(xù)改進(jìn)的方法。
（2）全局優(yōu)化 而非 局部?jī)?yōu)化
由于大部分按職能組織團(tuán)隊(duì)的企業(yè)內(nèi)部都存在部門(mén)割據(jù)的問(wèn)題，導(dǎo)致大家都在做本職能部門(mén)內(nèi)的局部?jī)?yōu)化，而沒(méi)人做部門(mén)間的整體優(yōu)化。有些部門(mén)間的扯皮時(shí)間甚至長(zhǎng)達(dá)數(shù)月，嚴(yán)重影響了產(chǎn)品的交付。這提醒我們，全局優(yōu)化來(lái)提高企業(yè)整體競(jìng)爭(zhēng)力，才是各個(gè)部門(mén)賴(lài)以生存的保障。
（3）單件流 高于 庫(kù)存
單件流指的是，正在制作的產(chǎn)品的各個(gè)模塊，能從最初的對(duì)其增加價(jià)值的加工步驟，直接傳遞到下一個(gè)增值加工步驟進(jìn)行加工，并最終被傳遞到客戶(hù)手中，在這個(gè)過(guò)程中，各個(gè)步驟之間沒(méi)有發(fā)生等待或者排隊(duì)的現(xiàn)象。而如果在各個(gè)步驟的傳遞過(guò)程中發(fā)生了等待或排隊(duì)，那就等同于建立了庫(kù)存。
軟件開(kāi)發(fā)中常見(jiàn)的庫(kù)存包括排隊(duì)等候開(kāi)發(fā)的需求、排隊(duì)等候測(cè)試的代碼、排隊(duì)等待修復(fù)的缺陷和排隊(duì)等待上線(xiàn)的產(chǎn)品特性;隱藏很深的庫(kù)存可能由諸如那些有固定期限(比如每月一次)的“用戶(hù)驗(yàn)收測(cè)試”的流程造成——月初幾天就開(kāi)發(fā)測(cè)試完畢的產(chǎn)品特性必須要被存放近一個(gè)月，等到月底“用戶(hù)驗(yàn)收測(cè)試”后才能繼續(xù)往下游走。
軟件開(kāi)發(fā)中的上述庫(kù)存就是讓項(xiàng)目延期的最大原因。而企業(yè)如果能做到單件流，那么就相當(dāng)于消滅了庫(kù)存，讓價(jià)值在不同環(huán)節(jié)之間流動(dòng)得最快，進(jìn)而實(shí)現(xiàn)了前文所提到的全局優(yōu)化。
4. 工具
（1）自動(dòng)化 高于 手工
按照固定流程所進(jìn)行的手工工作，比如手工回歸測(cè)試和手工部署工作，無(wú)趣、緩慢且無(wú)法審計(jì)。如果能將其代碼化，且用版本控制系統(tǒng)管理起來(lái)，并加以自動(dòng)化，這既能節(jié)省以后手工運(yùn)行的大量時(shí)間，又能體驗(yàn)到開(kāi)發(fā)測(cè)試和部署腳本工作的樂(lè)趣。
（2）基礎(chǔ)設(shè)施及代碼 高于 手工配置
傳統(tǒng)Ops的部署工作有些需要用鼠標(biāo)在界面上點(diǎn)來(lái)點(diǎn)去，效率很低;效率高一些的Ops用了自動(dòng)化腳本，但很多腳本都沒(méi)有進(jìn)行版本控制，更別提針對(duì)腳本的自動(dòng)化測(cè)試了。
如果能夠?qū)⒒A(chǔ)設(shè)施的維護(hù)工作都通過(guò)編寫(xiě)代碼并加以版本控制來(lái)完成，那么會(huì)帶來(lái)很多好處，比如Ops可以不用通過(guò)訪(fǎng)問(wèn)生產(chǎn)環(huán)境，就能知道生產(chǎn)環(huán)境上的配置情況;非運(yùn)維人員如Dev，就有機(jī)會(huì)去學(xué)習(xí)這些運(yùn)維配置代碼并且加以修改，提升整個(gè)團(tuán)隊(duì)的DevOps能力;另外工具能方便地讀取這些代碼，來(lái)自動(dòng)化地維護(hù)基層設(shè)施，大幅度提升Ops的工作效率。
（3）部署流水線(xiàn) 而非 每日構(gòu)建
程序員每天都會(huì)用代碼提交來(lái)為軟件系統(tǒng)增加價(jià)值。而如何有效地保證每次提交的代碼質(zhì)量過(guò)關(guān)而不會(huì)有損現(xiàn)有系統(tǒng)的價(jià)值呢?這就需要一個(gè)代碼構(gòu)建系統(tǒng)自動(dòng)地驗(yàn)證代碼在編譯、測(cè)試和打包等工作的過(guò)程中，是否符合質(zhì)量要求。
有些團(tuán)隊(duì)還在每晚做一次代碼構(gòu)建，這個(gè)昔日的“最佳”實(shí)踐如今已經(jīng)不再被推薦。一個(gè)團(tuán)隊(duì)程序員們每天代碼的提交會(huì)有很多，如果晚上構(gòu)建發(fā)現(xiàn)了錯(cuò)誤，第二天從這些眾多提交中發(fā)現(xiàn)誰(shuí)導(dǎo)致的錯(cuò)誤，將是一個(gè)很困難的事情。
推薦的做法是每一次代碼提交，都能自動(dòng)觸發(fā)部署流水線(xiàn)來(lái)檢查該提交是否通過(guò)了自動(dòng)化單元、驗(yàn)收和性能等測(cè)試。一旦發(fā)現(xiàn)問(wèn)題，就能輕松定位是誰(shuí)在哪個(gè)環(huán)節(jié)出現(xiàn)了什么問(wèn)題。
四、總結(jié)
DevOps的原則來(lái)自從業(yè)者們?cè)谌粘９ぷ髦羞\(yùn)用敏捷、精益原則的具體實(shí)踐。這些原則可以按照“人、產(chǎn)品、流程和工具”4個(gè)維度來(lái)組織。這些原則和實(shí)踐的目的，都是要實(shí)現(xiàn)DevOps的愿景——讓業(yè)務(wù)所要求的那些變化能隨時(shí)上線(xiàn)可用。
下圖是本文實(shí)例化DevOps原則的一個(gè)可視化總結(jié)。
【本文是專(zhuān)欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
分享題目：實(shí)例化DevOps原則：人、產(chǎn)品、流程和工具
文章鏈接：http://m.5511xx.com/article/cccoecg.html
