文／伍斌
【摘要】
- DevOps原則所追求的愿景蜈彼，就是“讓業(yè)務(wù)所要求的那些變化能隨時上線可用”窑眯；
- DevOps的起源表明氏淑，其原則是從Agile與Lean的實踐當(dāng)中提煉而來读整，因此與Agile和Lean的原則并無二致拒逮；
- 本文所討論的DevOps原則可以用“人罐氨、產(chǎn)品、流程和工具”這4個維度來進(jìn)行組織滩援。
【正文】
“你在做用戶故事拆分栅隐？這不是在做DevOps⊥婊玻”這是筆者在2016年以咨詢師的身份租悄，參與一家大型跨國金融企業(yè)的Agile和DevOps轉(zhuǎn)型時所聽到的話。在這家企業(yè)恩袱，Agile和DevOps明顯指的是不同的東西：前者專指每日站會泣棋、計劃會、回顧會等Scrum的實踐和用戶故事實踐畔塔；后者專指自動化潭辈、工具鏈和基礎(chǔ)設(shè)施等實踐纪吮。過了一段時間，筆者把本文所列舉的一些DevOps原則發(fā)到一個相關(guān)微信群里面萎胰，得到了這樣的反饋：“怎么滿眼都是敏捷和精益碾盟？”“感覺DevOps被一群不操作Op的人給玩兒壞了〖季梗”
這些經(jīng)歷讓筆者開始關(guān)心這些問題：既然Dev指的是“開發(fā)”冰肴，Ops指的是“運維”，那么到底什么是DevOps榔组？它的原則是什么熙尉？它和敏捷、精益的關(guān)系是什么搓扯？讓我們先觀察一下DevOps的起源检痰。
DevOps的起源可以分為兩條線
第一條線是:比利時獨立咨詢師Patrick Debois
2007年他在比利以咨詢師的身份，參與了一個政府?dāng)?shù)據(jù)中心遷移中的測試工作锨推。他在做測試時铅歼，需要頻繁往返于Dev團隊和Ops團隊之間。Dev團隊已經(jīng)實踐了敏捷换可，而Ops團隊還是傳統(tǒng)運維的工作方式椎椰。看到Ops團隊每天忙于救火和疲于奔命的狀態(tài)沾鳄，他在想：能否把敏捷的實踐引入Ops團隊呢慨飘？
第二條線是:當(dāng)時雅虎旗下的圖片分享網(wǎng)站Flickr
這家公司的運維部門經(jīng)理John Allspaw和工程師Paul Hammond，于2009年6月23日在美國圣荷西舉辦的Velocity 2009大會上译荞，發(fā)表了一個引燃DevOps的演講瓤的。這個演講的題目在當(dāng)時很搶眼－－《每天部署10次以上：Flickr公司的Dev與Ops的合作》。
這個演講有一個核心議題：Dev和Ops的目標(biāo)到底是不是沖突吞歼？傳統(tǒng)觀念認(rèn)為Dev和Ops的目標(biāo)是有沖突的——Dev的工作是添加新特性圈膏，而Ops的工作是保持系統(tǒng)運行的穩(wěn)定和快速；而Dev在添加新特性時所帶來的代碼變化浆熔，會導(dǎo)致系統(tǒng)運行不穩(wěn)定和變慢本辐，從而引發(fā)Dev與Ops的沖突桥帆。然而從全局來看医增，Dev和Ops的目標(biāo)是一致的，即都是“讓業(yè)務(wù)所要求的那些變化能隨時上線可用”老虫。
這樣搶眼的題目和鮮明的觀點叶骨，自然抓住了當(dāng)時還在比利時的Debois。他在“推特”上發(fā)帖：“可惜沒法去現(xiàn)場參加祈匙『龉簦”朋友Paul Nasrat回帖說：“為什么不在比利時搞一個你自己的Velocity大會天揖？”這兩條線使得Debois擼起袖子，于2009年10月30至31日跪帝，在比利時的第二大城市根特今膊，以社區(qū)自發(fā)的形式舉辦了一個名為DevOpsDays的大會。這次大會吸引了不少開發(fā)者伞剑、系統(tǒng)管理員和軟件工具程序員斑唬。這兩天大家聊得太開心了，會議結(jié)束還不過癮黎泣，回去繼續(xù)在“推特”上聊恕刘。限于推特140個字符的制約，Debois把DevOpsDays中的Days去掉抒倚，而創(chuàng)建了#DevOps#這個“推特”聊天主題標(biāo)簽褐着，DevOps誕生了。
Flickr公司的兩位演講者所表達(dá)的“Dev和Ops的共同目標(biāo)是讓業(yè)務(wù)所要求的那些變化能隨時上線可用”這一觀點托呕，其實就是DevOps的愿景含蓉。而要達(dá)到這一點，可以使用一個現(xiàn)成的工具：精益项郊。源自豐田生產(chǎn)方式的“精益”的愿景就是“Shortest lead time”谴餐，即用最短的時間來完成從客戶下訂單到收到貨物的全過程。這恰好能幫助實現(xiàn)DevOps的上述愿景呆抑∑裆ぃ《持續(xù)交付》的作者之一Jez Humble也體會出精益在DevOps中的重要性，以至于他把DevOps的CAMS框架修訂為CALMS鹊碍，其中增加的L指的就是Lean（精益）厌殉，這一點下文還會提及。
從上面DevOps的起源中能夠看出三點：
- DevOps源自草根社區(qū)侈咕，最初并沒有什么自上而下設(shè)計出來的理論框架公罕；
- DevOps背后的原則，就是上面兩條線中所涉及的敏捷和精益的原則耀销；
- DevOps的愿景是讓業(yè)務(wù)所要求的那些變化能隨時上線可用楼眷。
一旦了解了上面第2點，就不會有前文中所說的“Agile和DevOps是不同的東西”和“感覺DevOps被一群不操作Op的人給玩兒壞了”這樣的說法熊尉。
因為DevOps源自草根罐柳，沒有什么框架，所以如何定義DevOps成了DevOps社區(qū)里面的一個大難題狰住。一些DevOps從業(yè)者张吉，紛紛設(shè)定自己的DevOps框架。其中比較有名的框架有上文提到的Damon Edwards所定義并被Jez Humble所修訂的CALMS催植，和Gene Kim所定義的The Three Ways肮蛹。
CALMS:
- Culture – 文化：公司各個角色一起擔(dān)當(dāng)業(yè)務(wù)變化勺择，實現(xiàn)有效協(xié)作和溝通；
- Automation – 自動化：在價值鏈中盡量除去手工步驟伦忠；
- Lean – 精益：運用精益原則更頻繁地交付價值省核；
- Metrics – 度量：度量并使用數(shù)據(jù)來優(yōu)化交付周期；
- Sharing – 分享：分享成功和失敗的經(jīng)驗來相互學(xué)習(xí)昆码。
The Three Ways:
- The First Way： System Thinking （系統(tǒng)思考：強調(diào)全局優(yōu)化芳撒，避免局部優(yōu)化）；
- The Second Way： Amplify Feedback Loops （經(jīng)過放大的反饋回路：創(chuàng)建從開發(fā)過程下游至上游的反饋環(huán)）未桥；
- The Third Way： Culture of Continual Experimentation And Learning（持續(xù)做試驗和學(xué)習(xí)的文化：持續(xù)做試驗笔刹，承擔(dān)風(fēng)險、從失敗中學(xué)習(xí)冬耿；通過反復(fù)實踐來達(dá)到精通）舌菜。
(圖片來自：http://t.cn/RijRjYS)
本文試著從“人、產(chǎn)品亦镶、流程和工具”4個維度日月，來梳理DevOps的一些原則。為什么會有這4個維度缤骨？
先看前三個維度：“人”爱咬、“產(chǎn)品”和“流程”。在一百多年前的工業(yè)經(jīng)濟時代绊起，由于物質(zhì)匱乏精拟，所以當(dāng)時占主導(dǎo)地位的泰勒科學(xué)管理理論將“流程”這個維度放到了第一位，讓企業(yè)首先通過標(biāo)準(zhǔn)化的“流程”達(dá)到規(guī)氖幔化的制造能力蜂绎，來滿足供不應(yīng)求的市場。市場上可購買的商品少笋鄙，人們對“產(chǎn)品”的質(zhì)量师枣、設(shè)計也就不介意了，所以“產(chǎn)品”排在了第二位萧落。而標(biāo)準(zhǔn)化的流程把工人的素質(zhì)標(biāo)準(zhǔn)降到了最低践美，只要帶著一雙手來，在流水線上重復(fù)一個動作就好了找岖，不需要動腦子陨倡，因此“人”排在了最后的位置。
一百年后宣增，工業(yè)經(jīng)濟霸主的地位已被知識經(jīng)濟所取代玫膀。在具有知識密集特點的敏捷軟件開發(fā)的上下文中矛缨，這三個維度的順序顛倒了：“人”的優(yōu)先級最高爹脾，因為只有依靠“人”的創(chuàng)造力才能應(yīng)對多變的業(yè)務(wù)需求帖旨；給用戶提供價值的“產(chǎn)品”依舊排第二位，因為這是企業(yè)賴以生存的根基灵妨；而“流程”可以為了“人”來高效地實現(xiàn)“產(chǎn)品”而進(jìn)行定制解阅，所以優(yōu)先級最低。而強調(diào)自動化的DevOps離不開好用的“工具”泌霍，“工具”又可以依據(jù)流程來定制货抄，因而可以補在“流程”的后面。
(圖片來自：http://t.cn/RijRMrp)
下面所描述的DevOps原則朱转，來源于敏捷蟹地、精益和DevOps的一些具體實踐。雖然沒有涵蓋DevOps的所有實踐藤为，但已經(jīng)包括筆者最近一年在DevOps的實踐中所感悟的主要內(nèi)容怪与，而且今后會繼續(xù)完善腊敲。
一般的文章對于“原則”的闡述都比較抽象似踱，有點像上面提到的CALMS和The Three Ways這兩個框架的定義方式那樣——僅僅把幾個名詞或短語放到那里。對于不熟悉Agile男公、Lean和DevOps的人來說存淫，看了上述框架還是不知道DevOps到底是做啥的耘斩。
為了讓DevOps原則的描述更加具體生動，筆者參考敏捷宣言的寫法和實例化需求的做法（即用具體的實際例子來編寫驗收條件）桅咆，使用了“高于”和“而非”的句式來對比兩個具體實踐的實例括授，且盡量用一些具體的實踐來代表相應(yīng)的原則，如“部署流水線”等岩饼。其中刽脖，“高于”表示右邊的實踐雖然不如左邊的好，但還是有價值的忌愚∏埽“而非”表示右邊的實踐并不值得推薦。這就是本文標(biāo)題中“實例化”的由來硕糊。
1. 人
領(lǐng)導(dǎo)者身體力行持續(xù)改進(jìn) 高于 關(guān)注工具和基礎(chǔ)設(shè)施
很多企業(yè)（包括筆者所輔導(dǎo)的企業(yè)）都在實踐DevOps院水。要想讓DevOps這顆樹苗茁壯成長，企業(yè)要為其提供一個良好的土壤——即企業(yè)文化简十。而企業(yè)文化檬某，是企業(yè)領(lǐng)導(dǎo)者引導(dǎo)塑造的。DevOps對于國內(nèi)大部分企業(yè)來說螟蝙，都是一個前所未有的新事物恢恼。必須通過不斷做試驗，才能找到培育它生長的土壤方胰默，做試驗就是為持續(xù)改進(jìn)做準(zhǔn)備场斑。筆者所輔導(dǎo)的企業(yè)漓踢，工程師被項目進(jìn)度壓得喘不過氣來，根本沒有時間學(xué)習(xí)新工具和新方法漏隐，更別提做試驗了喧半。
(圖片來自：http://www.yes123.com.tw/)
所以只有領(lǐng)導(dǎo)者身體力行，不僅自己親自做試驗和進(jìn)行持續(xù)改進(jìn)青责，并給工程師足夠的時間來做試驗和持續(xù)改進(jìn)挺据，這樣所創(chuàng)造出良好的環(huán)境，才能讓那些自動化工具和基礎(chǔ)設(shè)施在企業(yè)內(nèi)部得到有效利用脖隶。
試驗并改進(jìn)流程 而非 指責(zé)人的過失
豐田公司有一句口號：“對流程苛扁耐，對人員柔”，意思是說：每位員工都會盡力做好工作的产阱，那些在工作中所出現(xiàn)的問題都是流程的問題做葵。因為根據(jù)這種有問題的流程來工作，無論是誰都會出同樣的問題心墅。前面說過酿矢，DevOps對于國內(nèi)大部分企業(yè)都是新事物，需要做試驗來“摸著石頭過河”怎燥，做試驗就有失敗的時候瘫筐，此時就要調(diào)整流程，而不是怪罪于人铐姚，否則企業(yè)沒有人會去繼續(xù)嘗試DevOps策肝。
產(chǎn)品思維 高于 項目思維
根據(jù)這一個原則可以定義“人”的組織結(jié)構(gòu)——團隊結(jié)構(gòu)，即可以按照產(chǎn)品而不是項目來組建團隊隐绵。這樣的產(chǎn)品團隊包括了Dev之众、Ops、BA依许、Tester棺禾、PO和Architect等各種角色，他們相互配合且不依靠團隊以外的其他角色就能獨立自主地交付軟件產(chǎn)品峭跳，這個產(chǎn)品團隊負(fù)責(zé)該產(chǎn)品從生到死的全生命周期膘婶，并且只要產(chǎn)品還在，這個團隊就不會解散蛀醉。這種設(shè)置會讓團隊的不同角色目標(biāo)一致悬襟，比起從目標(biāo)不一致的各種職能團隊（比如Dev團隊、Tester團隊和BA團隊）抽調(diào)人員拼湊成臨時的項目團隊拯刁，磨合期更短脊岳，更加有戰(zhàn)斗力。
2. 產(chǎn)品
質(zhì)量和安全內(nèi)建 而非 晚期度量和檢查
產(chǎn)品需要質(zhì)量和安全來保證價值。人們長期認(rèn)為“高質(zhì)量”意味著“高成本”割捅，因為要維護(hù)高質(zhì)量奶躯，需要在產(chǎn)品出廠前做大批量檢測，并銷毀那些次品棺牧，這就花費了高昂的成本巫糙。但豐田公司卻說“高質(zhì)量是免費的”朗儒。這是怎么做到的呢颊乘？這其實就是前文提到的豐田公司“對流程苛”的結(jié)果。豐田公司通過持續(xù)改進(jìn)流程醉锄，“一次就把事情做對”乏悄，這樣就能在脫離后期大規(guī)模檢查的情況下保證高質(zhì)量，同時其成本也趨近于零恳不。
客戶反饋 高于 按期交付
產(chǎn)品是否實現(xiàn)了價值檩小，只有通過客戶的反饋才能知道。很多團隊往往過分關(guān)注交付期限烟勋，而忽視客戶反饋规求。這樣做的后果，就是雖然按期交付卵惦，但是產(chǎn)品卻不是客戶所期望的阻肿，造成返工或項目失敗。
基于不可變?nèi)萜鞯奈⒎?wù) 高于 單塊應(yīng)用
產(chǎn)品需要能快速地開發(fā)沮尿、測試和部署才能有效地交付價值丛塌。對于復(fù)雜度高的大型產(chǎn)品，如果可以由多個微服務(wù)組合而成畜疾，每個微服務(wù)都能獨立地開發(fā)赴邻、測試、部署和上線啡捶。這比起必須集成各個模塊才能進(jìn)行手工測試的單塊應(yīng)用來說姥敛，更能實現(xiàn)各個微服務(wù)之間的并行研發(fā)，加快每個微服務(wù)的開發(fā)下游至上游的反饋環(huán)的反饋速度瞎暑，進(jìn)而縮短項目進(jìn)度徒溪，讓價值交付得更快。
不可變?nèi)萜髦傅氖擒浖a(chǎn)品被封裝到一個類似docker這樣的容器內(nèi)上線金顿，且上線后不可手工修改其配置臊泌。如果一定要修改，也只能通過部署流水線把要修改的內(nèi)容重新打包成另一個新的不可變?nèi)萜鱽砩暇€揍拆。這樣做的好處是能夠?qū)崿F(xiàn)部署和發(fā)布自動化以及進(jìn)行更好的版本控制渠概，消除線上手工配置所帶來的無法審計的風(fēng)險。這一實踐是本文寫作時期的推薦實踐，該實踐今后還會繼續(xù)演進(jìn)播揪。
3. 流程
管理層實踐Improvement Kata和Coaching Kata進(jìn)行流程持續(xù)改進(jìn) 高于 用結(jié)果導(dǎo)向進(jìn)行管理
佛家說：“菩薩畏因贮喧，眾生畏果”。傳統(tǒng)按結(jié)果導(dǎo)向進(jìn)行管理的一個弊病猪狈，就是團隊成員會把注意力放到結(jié)果上箱沦，而不是產(chǎn)生這樣結(jié)果的原因——即過程改進(jìn)之上。這樣的后果就是雇庙，大家會把精力放到如何讓報表好看谓形，而不是真正地提高團隊成員的持續(xù)改進(jìn)能力來真正達(dá)到所期望的結(jié)果。
企業(yè)管理層可以參考《豐田套路》一書來帶頭實踐Improvement Kata和Coaching Kata疆前，讓企業(yè)產(chǎn)生持續(xù)改進(jìn)的文化寒跳。其中，Improvement Kata是通過一系列“確定目標(biāo)—>考察現(xiàn)狀—>識別困難—>制定方案—>觀察成效”的PDCA反饋環(huán)來做持續(xù)改進(jìn)竹椒；Coaching Kata是通過導(dǎo)師“一對一帶學(xué)徒”的方式來讓企業(yè)全員掌握持續(xù)改進(jìn)的方法童太。
全局優(yōu)化 而非 局部優(yōu)化
由于大部分按職能組織團隊的企業(yè)內(nèi)部都存在部門割據(jù)的問題，導(dǎo)致大家都在做本職能部門內(nèi)的局部優(yōu)化胸完，而沒人做部門間的整體優(yōu)化书释。有些部門間的扯皮時間甚至長達(dá)數(shù)月，嚴(yán)重影響了產(chǎn)品的交付赊窥。這提醒我們爆惧，全局優(yōu)化來提高企業(yè)整體競爭力，才是各個部門賴以生存的保障誓琼。
單件流 高于 庫存
單件流指的是检激，正在制作的產(chǎn)品的各個模塊，能從最初的對其增加價值的加工步驟腹侣，直接傳遞到下一個增值加工步驟進(jìn)行加工叔收，并最終被傳遞到客戶手中，在這個過程中傲隶，各個步驟之間沒有發(fā)生等待或者排隊的現(xiàn)象饺律。而如果在各個步驟的傳遞過程中發(fā)生了等待或排隊，那就等同于建立了庫存跺株。
軟件開發(fā)中常見的庫存包括排隊等候開發(fā)的需求复濒、排隊等候測試的代碼、排隊等待修復(fù)的缺陷和排隊等待上線的產(chǎn)品特性乒省；隱藏很深的庫存可能由諸如那些有固定期限（比如每月一次）的“用戶驗收測試”的流程造成——月初幾天就開發(fā)測試完畢的產(chǎn)品特性必須要被存放近一個月巧颈，等到月底“用戶驗收測試”后才能繼續(xù)往下游走。軟件開發(fā)中的上述庫存就是讓項目延期的最大原因袖扛。而企業(yè)如果能做到單件流砸泛，那么就相當(dāng)于消滅了庫存十籍，讓價值在不同環(huán)節(jié)之間流動得最快，進(jìn)而實現(xiàn)了前文所提到的全局優(yōu)化唇礁。
4. 工具
自動化 高于 手工
按照固定流程所進(jìn)行的手工工作勾栗，比如手工回歸測試和手工部署工作，無趣盏筐、緩慢且無法審計围俘。如果能將其代碼化，且用版本控制系統(tǒng)管理起來琢融，并加以自動化界牡，這既能節(jié)省以后手工運行的大量時間，又能體驗到開發(fā)測試和部署腳本工作的樂趣吏奸。
基礎(chǔ)設(shè)施及代碼 高于 手工配置
傳統(tǒng)Ops的部署工作有些需要用鼠標(biāo)在界面上點來點去欢揖，效率很低陶耍；效率高一些的Ops用了自動化腳本奋蔚，但很多腳本都沒有進(jìn)行版本控制，更別提針對腳本的自動化測試了烈钞。
如果能夠?qū)⒒A(chǔ)設(shè)施的維護(hù)工作都通過編寫代碼并加以版本控制來完成泊碑，那么會帶來很多好處，比如Ops可以不用通過訪問生產(chǎn)環(huán)境毯欣，就能知道生產(chǎn)環(huán)境上的配置情況馒过；非運維人員如Dev，就有機會去學(xué)習(xí)這些運維配置代碼并且加以修改酗钞，提升整個團隊的DevOps能力腹忽；另外工具能方便地讀取這些代碼，來自動化地維護(hù)基層設(shè)施砚作，大幅度提升Ops的工作效率窘奏。
部署流水線 而非 每日構(gòu)建
程序員每天都會用代碼提交來為軟件系統(tǒng)增加價值。而如何有效地保證每次提交的代碼質(zhì)量過關(guān)而不會有損現(xiàn)有系統(tǒng)的價值呢葫录？這就需要一個代碼構(gòu)建系統(tǒng)自動地驗證代碼在編譯着裹、測試和打包等工作的過程中，是否符合質(zhì)量要求米同。
有些團隊還在每晚做一次代碼構(gòu)建骇扇，這個昔日的“最佳”實踐如今已經(jīng)不再被推薦。一個團隊程序員們每天代碼的提交會有很多面粮，如果晚上構(gòu)建發(fā)現(xiàn)了錯誤少孝，第二天從這些眾多提交中發(fā)現(xiàn)誰導(dǎo)致的錯誤，將是一個很困難的事情熬苍。推薦的做法是每一次代碼提交稍走，都能自動觸發(fā)部署流水線來檢查該提交是否通過了自動化單元、驗收和性能等測試。一旦發(fā)現(xiàn)問題钱磅，就能輕松定位是誰在哪個環(huán)節(jié)出現(xiàn)了什么問題梦裂。
總結(jié)
DevOps的原則來自從業(yè)者們在日常工作中運用敏捷、精益原則的具體實踐盖淡。這些原則可以按照“人年柠、產(chǎn)品、流程和工具”4個維度來組織褪迟。這些原則和實踐的目的冗恨，都是要實現(xiàn)DevOps的愿景——讓業(yè)務(wù)所要求的那些變化能隨時上線可用。
下圖是本文實例化DevOps原則的一個可視化總結(jié)味赃。
