DevOps原則所追求的愿景，就是“讓業(yè)務(wù)所要求的那些變革能隨時(shí)上線可用”；DevOps的起源表白，其原則是從Agile與Lean的實(shí)踐傍邊提煉而來，因此與Agile和Lean的原則并無二致；本文所討論的DevOps原則可以用“人、產(chǎn)品、流程和工具”這4個(gè)維度來進(jìn)行組織。

“你在做用戶故事拆分？這不是在做DevOps?！边@是筆者在2016年以咨詢師的身份，參與一家大型跨國(guó)金融企業(yè)的Agile和DevOps轉(zhuǎn)型時(shí)所聽到的話。在這家企業(yè)，Agile和DevOps明顯指的是差別的東西：前者專指每日站會(huì)、計(jì)劃會(huì)、回顧會(huì)等Scrum的實(shí)踐和用戶故事實(shí)踐；后者專指自動(dòng)化、工具鏈和基礎(chǔ)設(shè)施等實(shí)踐。過了一段時(shí)間，筆者把本文所列舉的一些DevOps原則發(fā)到一個(gè)相關(guān)微信群里面，得到了這樣的反饋：“怎么滿眼都是敏捷和精益？”“感覺DevOps被一群不操作Op的人給玩兒壞了?！?/p>

這些經(jīng)歷讓筆者開始關(guān)心這些問題：既然Dev指的是“開發(fā)”，Ops指的是“運(yùn)維”，那么到底什么是DevOps？它的原則是什么？它和敏捷、精益的關(guān)系是什么？讓我們先不雅觀察一下DevOps的起源。

DevOps的起源可以分為兩條線第一條線：比利時(shí)獨(dú)立咨詢師Patrick Debois

2007年他在比利以咨詢師的身份，參與了一個(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ì)呢？

第二條線：當(dāng)時(shí)雅虎旗下的圖片分享網(wǎng)站Flickr

這家公司的運(yùn)維部門經(jīng)理John Allspaw和工程師Paul Hammond，于2009年6月23日在美國(guó)圣荷西舉辦的Velocity 2009大會(huì)上，頒發(fā)了一個(gè)引燃DevOps的演講。這個(gè)演講的標(biāo)題問題在當(dāng)時(shí)很搶眼——《每天安排10次以上：Flickr公司的Dev與Ops的合作》。

這個(gè)演講有一個(gè)核心議題：Dev和Ops的目標(biāo)到底是不是沖突？傳統(tǒng)不雅觀念認(rèn)為Dev和Ops的目標(biāo)是有沖突的——Dev的工作是添加新特性，而Ops的工作是連結(jié)系統(tǒng)運(yùn)行的不變和快速；而Dev在添加新特性時(shí)所帶來的代碼變革，會(huì)導(dǎo)致系統(tǒng)運(yùn)行不不變和變慢，從而引發(fā)Dev與Ops的沖突。然而從全局來看，Dev和Ops的目標(biāo)是一致的，即都是“讓業(yè)務(wù)所要求的那些變革能隨時(shí)上線可用”。

這樣搶眼的標(biāo)題問題和鮮明的不雅觀點(diǎn)，自然抓住了當(dāng)時(shí)還在比利時(shí)的Debois。他在“推特”上發(fā)帖：“可惜沒法去現(xiàn)場(chǎng)參加?！卑閭HPaul Nasrat回帖說：“為什么不在比利時(shí)搞一個(gè)你本身的Velocity大會(huì)？”這兩條線使得Debois擼起袖子，于2009年10月30至31日，在比利時(shí)的第二大城市根特，以社區(qū)自發(fā)的形式舉辦了一個(gè)名為DevOpsDays的大會(huì)。這次大會(huì)吸引了不少開發(fā)者、系統(tǒng)辦理員和軟件工具程序員。這兩天大家聊得太開心了，會(huì)議結(jié)束還不過癮，回去繼續(xù)在“推特”上聊。限于推特140個(gè)字符的制約，Debois把DevOpsDays中的Days去掉，而創(chuàng)建了#DevOps#這個(gè)“推特”聊天主題標(biāo)簽，DevOps誕生了。

Flickr公司的兩位演講者所表達(dá)的“Dev和Ops的共同目標(biāo)是讓業(yè)務(wù)所要求的那些變革能隨時(shí)上線可用”這一不雅觀點(diǎn)，其實(shí)就是DevOps的愿景。而要達(dá)到這一點(diǎn)，可以使用一個(gè)現(xiàn)成的工具：精益。源自豐田生產(chǎn)方式的“精益”的愿景就是“Shortest lead time”，即用最短的時(shí)間來完成從客戶下訂單到收到貨物的全過程。這恰好能幫手實(shí)現(xiàn)DevOps的上述愿景?！冻掷m(xù)交付》的作者之一Jez Humble也體會(huì)出精益在DevOps中的重要性，以至于他把DevOps的CAMS框架修訂為CALMS，其中增加的L指的就是Lean（精益），這一點(diǎn)下文還會(huì)提及。

從上面DevOps的起源中能夠看出三點(diǎn)：

DevOps源自草根社區(qū)，最初并沒有什么自上而下設(shè)計(jì)出來的理論框架；DevOps背后的原則，就是上面兩條線中所涉及的敏捷和精益的原則；DevOps的愿景是讓業(yè)務(wù)所要求的那些變革能隨時(shí)上線可用。

一旦了解了上面第2點(diǎn)，就不會(huì)有前文中所說的“Agile和DevOps是差別的東西”和“感覺DevOps被一群不操作Op的人給玩兒壞了”這樣的說法。

因?yàn)镈evOps源自草根，沒有什么框架，所以如何定義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ù)來優(yōu)化交付周期；Sharing – 分享：分享成功和失敗的經(jīng)驗(yàn)來彼此學(xué)習(xí)。

標(biāo)簽：林芝 東營(yíng) 烏魯木齊 九江 鹽城