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

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

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

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

2007年他在比利以咨詢師的身份，參與了一個政府數據中心遷移中的測試工作。他在做測試時，需要頻繁往返于Dev團隊和Ops團隊之間。Dev團隊已經實踐了敏捷，而Ops團隊還是傳統運維的工作方式。看到Ops團隊每天忙于救火和疲于奔命的狀態，他在想：能否把敏捷的實踐引入Ops團隊呢？

第二條線：當時雅虎旗下的圖片分享網站Flickr

這家公司的運維部門經理John Allspaw和工程師Paul Hammond，于2009年6月23日在美國圣荷西舉辦的Velocity 2009大會上，頒發了一個引燃DevOps的演講。這個演講的標題問題在當時很搶眼——《每天安排10次以上：Flickr公司的Dev與Ops的合作》。

這個演講有一個核心議題：Dev和Ops的目標到底是不是沖突？傳統不雅觀念認為Dev和Ops的目標是有沖突的——Dev的工作是添加新特性，而Ops的工作是連結系統運行的不變和快速；而Dev在添加新特性時所帶來的代碼變革，會導致系統運行不不變和變慢，從而引發Dev與Ops的沖突。然而從全局來看，Dev和Ops的目標是一致的，即都是“讓業務所要求的那些變革能隨時上線可用”。

這樣搶眼的標題問題和鮮明的不雅觀點，自然抓住了當時還在比利時的Debois。他在“推特”上發帖：“可惜沒法去現場參加。”伴侶Paul Nasrat回帖說：“為什么不在比利時搞一個你本身的Velocity大會？”這兩條線使得Debois擼起袖子，于2009年10月30至31日，在比利時的第二大城市根特，以社區自發的形式舉辦了一個名為DevOpsDays的大會。這次大會吸引了不少開發者、系統辦理員和軟件工具程序員。這兩天大家聊得太開心了，會議結束還不過癮，回去繼續在“推特”上聊。限于推特140個字符的制約，Debois把DevOpsDays中的Days去掉，而創建了#DevOps#這個“推特”聊天主題標簽，DevOps誕生了。

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

從上面DevOps的起源中能夠看出三點：

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

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

因為DevOps源自草根，沒有什么框架，所以如何定義DevOps成了DevOps社區里面的一個大難題。一些DevOps從業者，紛紛設定本身的DevOps框架。其中比較有名的框架有上文提到的Damon Edwards所定義并被Jez Humble所修訂的CALMS，和Gene Kim所定義的The Three Ways。

CALMS:

Culture – 文化：公司各個角色一起擔當業務變革，實現有效協作和溝通；Automation – 自動化：在價值鏈中盡量除去手工步驟；Lean – 精益：運用精益原則更頻繁地交付價值；Metrics – 度量：度量并使用數據來優化交付周期；Sharing – 分享：分享成功和失敗的經驗來彼此學習。

標簽：林芝 東營 烏魯木齊 九江 鹽城