用工具堆砌的DevOps 幻覺
在第一屆 DevOpsDays結(jié)束后，DevOps 運(yùn)動則如星火燎原之勢在全球發(fā)展開來皇忿。隨著 DevOps 思想的不斷傳播葡幸，相對的質(zhì)疑和批評也從未停止過。以至于到今天對于 DevOps 的定義還是眾說紛紜朗恳，爭論不休湿颅。
當(dāng)人們還在爭論 DevOps的時(shí)候，一批基于敏捷的工程實(shí)踐和自動化工具帶著 DevOps 的標(biāo)簽走入了人們的視野僻肖。人們開始認(rèn)為 DevOps 就是使用這些工具進(jìn)行自動化肖爵。
在早期的 DevOps實(shí)踐里，開發(fā)和運(yùn)維仍然是分離的臀脏。而在很多企業(yè)中劝堪，運(yùn)維部門往往是核心部門，評審應(yīng)用軟件的架構(gòu)設(shè)計(jì)和上線要求揉稚。于是運(yùn)維部門開始利用這些被稱作為“DevOps”的自動化工具管理設(shè)備和應(yīng)用系統(tǒng)秒啦。并且將自己相關(guān)的實(shí)踐打賞了“DevOps”的標(biāo)簽傳播開來。
于此同時(shí)搀玖，開發(fā)團(tuán)隊(duì)開始采用這些工具構(gòu)建開發(fā)用的測試環(huán)境余境。并將運(yùn)維需求帶入了開發(fā)流程中，這促進(jìn)了內(nèi)建質(zhì)量灌诅。并且利用持續(xù)集成服務(wù)器（ Continous Integration Serever） 構(gòu)建持續(xù)交付流水線（Continuous delivery pipeline）來可視化軟件交付的進(jìn)度和流程芳来，并通過流水線完成了自動化部署。持續(xù)集成服務(wù)器連接了開發(fā)和運(yùn)維猜拾！
這就是DevOps 即舌？
“同床異夢” 的 DevOps
雖然開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)使用的工具變了，然而事情卻沒有改變：我們?nèi)匀荒芸吹健绷鞒探Y(jié)合在一起挎袜，但工作目標(biāo)仍然分離“的兩個(gè)團(tuán)隊(duì)：運(yùn)維團(tuán)隊(duì)仍然牢牢控制著環(huán)境顽聂，控制著上線標(biāo)準(zhǔn)和上線流程肥惭。通過補(bǔ)充更多自動化的測試和驗(yàn)證手段構(gòu)建更加嚴(yán)格的控制著變更的入口和出口。開發(fā)團(tuán)隊(duì)仍然不停的為了滿足運(yùn)維團(tuán)隊(duì)制定的更加嚴(yán)格的開發(fā)規(guī)范更加努力的學(xué)習(xí)各種工具而不斷加班紊搪。
運(yùn)維團(tuán)隊(duì)仍然不關(guān)心開發(fā)團(tuán)隊(duì)是否需要幫助蜜葱，開發(fā)團(tuán)隊(duì)也依然不了解運(yùn)維團(tuán)隊(duì)在做什么。如果沒有 DevOps文化的建立耀石，DevOps 僅僅是“通過自動化工具和手段構(gòu)建的標(biāo)準(zhǔn)流程”而已牵囤。
有人甚至開始把這兩個(gè)團(tuán)隊(duì)融合在了一起，變成了一個(gè)團(tuán)隊(duì)娶牌。這在一定程度上緩解了這種矛盾奔浅，但是相互指責(zé)卻并沒有讓團(tuán)隊(duì)凝聚起來更加具有戰(zhàn)斗力。而是變成了一個(gè)緩慢而爭論不休的“Dev和Ops 法庭”：項(xiàng)目經(jīng)理或者產(chǎn)品經(jīng)理成為了法官诗良，Dev 和 Ops 則輪番成為原告和被告汹桦。
這不是DevOps !
早期的 DevOps文化：信任和尊重
早在 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” 的演講里，就總結(jié)出了 Dev 和 Ops 的合作并不能僅僅只有工具鉴裹，還需要依托文化把某些行為和價(jià)值觀帶到組織內(nèi)部舞骆。這個(gè)演講很有洞見的總結(jié)了 Dev 和 Ops 的不同觀點(diǎn)和思維模式，并從 Dev 和 Ops 的立場分別給出了促進(jìn)合作的建議径荔。這其中包括：
尊重：避免成見并尊重他人的經(jīng)驗(yàn)督禽，觀點(diǎn)和責(zé)任。不要只是一味的拒絕改變总处，或者把隱藏細(xì)節(jié)狈惫。對于Dev 來說，當(dāng)和 Ops 交流的時(shí)候鹦马，則應(yīng)該告訴代碼對 Ops 工作的影響胧谈。
信任：對于 Ops 來說，他們應(yīng)該相信 Dev 新增加的功能荸频。對于 Dev 來說菱肖，他們 應(yīng)該相信 Ops 對基礎(chǔ)設(shè)施的改動，而且每個(gè)人都應(yīng)該相信對方已經(jīng)做到最好旭从。 Ops 應(yīng)該更加透明稳强，不光需要分享運(yùn)行指南和故障預(yù)案，而且還要給 Dev 能夠訪問機(jī)器的權(quán)限和悦。
對失敗的健康態(tài)度：盡管經(jīng)過層層嚴(yán)格的測試退疫，失敗在很多情況下是無法避免的。但如果能像飛機(jī)的安全說明那樣制定出應(yīng)急預(yù)案鸽素，則可以在失敗后盡可能的減少損失蹄咖。
避免指責(zé)：指責(zé)會把大量的時(shí)間花在問題責(zé)任的界定而非問題的解決上。對于 Dev 來說付鹿，他們需要時(shí)刻記得當(dāng)他們寫下的 代碼搞砸了之后澜汤，總會有 Ops 半夜第一個(gè)被叫醒去解決問題。而對于 Ops 來說舵匾，需要給當(dāng)前的狀況有建設(shè)性的建議和反饋俊抵，而不僅僅是抱怨和指責(zé) 。
缺失的 DevOps文化建設(shè) —— 用技術(shù)升級粉飾制度問題
在很多管理層看來坐梯，這些不可思議的做法顛覆了經(jīng)典的運(yùn)維管理經(jīng)驗(yàn)徽诲，看起來很美好而往往和現(xiàn)有的制度存在沖突而難以落地。另一方面吵血，工程師卻很向往這樣一種夢想的工作環(huán)境谎替，可以擺脫那些無意義爭斗和約束，做真正有意義的事情蹋辅。
而在一個(gè)對變革抵觸钱贯，對冒險(xiǎn)和失敗不寬容的環(huán)境下，人們往往傾向于不作為侦另，讓事情不斷變壞秩命。并寄希望于管理人員。而在這種制度下褒傅，管理人員往往傾向于做表面文章弃锐，相較于改變現(xiàn)有的制度和習(xí)慣，購買技術(shù)是最方便殿托，效果最明顯霹菊，風(fēng)險(xiǎn)最低的手段，這會讓一切”看起來很美好“支竹。
而在 DevOps改進(jìn)中旋廷，技術(shù)往往是最容易的部分，只要找到供應(yīng)商或解決方案提供商購買就可以了唾戚。然而這并沒有解決組織的沖突柳洋，只是突擊的償還了一部分技術(shù)債務(wù)而已。技術(shù)仍然是被用來粉飾制度問題的“修正液“叹坦。
當(dāng)你有了 DevOps文化的團(tuán)隊(duì)熊镣，你無需擔(dān)心技術(shù)水平。因?yàn)檫@樣的團(tuán)隊(duì)會找到最合適的工具完成目標(biāo)募书。但是你擁有了 DevOps 的工具绪囱，得到的則是提高效率的組織孤島。
Netflix就是這樣一個(gè)例子莹捡，Netflix是全球十大視頻網(wǎng)站中唯一的收費(fèi)站點(diǎn)鬼吵。 盡管仍落后于YouTube和Hulu等在線視頻巨頭，但Netflix的發(fā)展速度遠(yuǎn)遠(yuǎn)高于競爭對手篮赢。此外齿椅，Netflix 在微服務(wù)和 DevOps 的實(shí)踐上一直走在業(yè)界的前沿琉挖。
早在2009年， Netflix的CEO和首席人才官就做了一份127頁的PPT涣脚，命名為《自由&責(zé)任的文化》示辈，這份PPT在網(wǎng)上被查閱超過了600萬次，甚至被Facebook公司的COO桑德伯格稱為“硅谷最重要的文件”遣蚀。
這份 PPT說明了一個(gè)重要的問題矾麻，保持領(lǐng)先的關(guān)鍵不在于你是否擁有先進(jìn)的技術(shù)（很多技術(shù)一開始都沒有，都是 Netflix 的員工自己創(chuàng)造）芭梯，最優(yōu)秀的員工（很多員工都是其它公司的普通員工）险耀，而在于你是否擁有可以留住人才和發(fā)揮人才價(jià)值的制度。
DevOps文化的特征
那么玖喘，DevOps的文化看起來應(yīng)該是什么樣的呢店煞？
在 Martin Fowler 的博客上躏碳，Rouan Wilsenach則作為一個(gè)觀察者進(jìn)一步從外部特征上描述了DevOps文化扛稽。他認(rèn)為DevOps文化的主要特征是"增加了開發(fā)和運(yùn)維的合作"物延，為了支持這種合作的發(fā)生，需要在團(tuán)隊(duì)內(nèi)部的文化和企業(yè)組織的文化上進(jìn)行兩方面的調(diào)整费尽。如下圖所示：
責(zé)任共擔(dān)（Shared Responsibility）
從團(tuán)隊(duì)內(nèi)部講赠群，責(zé)任共擔(dān)而不是 責(zé)任劃分 的制度會鼓勵(lì)合作的發(fā)生。責(zé)任邊界清晰旱幼，每個(gè)人都傾向于做好分內(nèi)事查描，而不會關(guān)心工作流上游或者是工作流下游里別人的事。
如果開發(fā)團(tuán)隊(duì)無需對系統(tǒng)上線后的維護(hù)和負(fù)責(zé)人柏卤，他們自然對運(yùn)維沒有興趣冬三。只有讓開發(fā)團(tuán)隊(duì)全程介入整個(gè)開發(fā)到運(yùn)維的流程，他們才能對運(yùn)維的痛點(diǎn)感同身受缘缚，在開發(fā)過程中加入對運(yùn)維的考量勾笆。此外，開發(fā)團(tuán)隊(duì)還會從對生產(chǎn)環(huán)境的監(jiān)控中發(fā)現(xiàn)新的需求桥滨。
如果運(yùn)維團(tuán)隊(duì)分擔(dān)開發(fā)團(tuán)隊(duì)的業(yè)務(wù)目標(biāo)和責(zé)任窝爪，他們就會更加理解開發(fā)團(tuán)隊(duì)對運(yùn)維的要求并且和開發(fā)團(tuán)隊(duì)工作的更加緊密。然而在實(shí)踐中齐媒，合作經(jīng)常起始于 Dev產(chǎn)生的產(chǎn)品運(yùn)維意識（例如部署和監(jiān)控）蒲每，以及在開發(fā)過程向運(yùn)維團(tuán)隊(duì)中學(xué)習(xí)到的實(shí)踐和自動化工具。
沒有組織孤島（No Silos)
從組織方面講喻括，在開發(fā)和運(yùn)維之間沒有孤島（No Silos)是組織調(diào)整的必要邀杏。適當(dāng)?shù)恼{(diào)整資源的結(jié)構(gòu)，讓運(yùn)維的同事在早期就加入團(tuán)隊(duì)并一起工作對構(gòu)建合作的文化是非常有幫助的唬血。而“交接”和“審批”并不是一個(gè)責(zé)任共擔(dān)的工作方式望蜡。這不會導(dǎo)致開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)合作唤崭，反而會引起指責(zé)的文化。所以泣特，開發(fā)和運(yùn)維的團(tuán)隊(duì)必須都要對系統(tǒng)變更的成敗負(fù)責(zé)浩姥。當(dāng)然，這無可避免的會導(dǎo)致開發(fā)和運(yùn)維的分界線會越來越模糊状您。
一個(gè)常見的反模式就是“分離的 DevOps 團(tuán)隊(duì)”，它一方面創(chuàng)造了新的孤島兜挨，另一方面組織了 DevOps 文化在整個(gè)組織內(nèi)的傳播膏孟。
自治的團(tuán)隊(duì)（Autonomous teams）
組織另外一個(gè)極具價(jià)值的轉(zhuǎn)變是自治團(tuán)隊(duì) （Autonomous teams），為了讓開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)工作的更有效率拌汇，需要讓團(tuán)隊(duì)能夠直接處理變革而不是經(jīng)過錯(cuò)綜復(fù)雜的決策過程柒桑。這需要信任團(tuán)隊(duì)，改變風(fēng)險(xiǎn)管理的方式并創(chuàng)建一個(gè)對失敗相對寬容的環(huán)境噪舀。
質(zhì)量內(nèi)建于開發(fā)流程中（building quality into the development process）
DevOps文化的轉(zhuǎn)變帶來的一個(gè)效果是讓新代碼進(jìn)入生產(chǎn)環(huán)境更加容易魁淳。這使一些未來的 DevOps 文化轉(zhuǎn)變非常必要。為了確保生產(chǎn)環(huán)境的變更穩(wěn)妥与倡。團(tuán)隊(duì)需要重視“將質(zhì)量構(gòu)建在開發(fā)過程中”界逛，這包括很多跨功能的考慮例如性能和安全，持續(xù)交付和自我測試的代碼會形成一個(gè)允許頻繁且低風(fēng)險(xiǎn)部署的基礎(chǔ)纺座。
反饋（Feedback)
團(tuán)隊(duì)也要重視反饋息拜，為了持續(xù)改進(jìn)， Dev和 Ops 就像系統(tǒng)自身一樣净响，緊密的工作在一起少欺。產(chǎn)品環(huán)境的監(jiān)控是一個(gè)對于診斷錯(cuò)誤和曝光潛在改進(jìn)的非常有幫助的反饋環(huán)。
自動化（Automation）
自動化是 DevOps運(yùn)動以及促進(jìn)合作的基石馋贤。將測試赞别、配置和部署自動化可以讓人們釋放出更多的精力，并專注于更有價(jià)值的活動配乓，此外還能減少人為失誤仿滔。而且，自動化腳本和自動化測試可以成為一個(gè)活文檔扰付，實(shí)時(shí)跟蹤在線系統(tǒng)配置的變更歷史堤撵。舉個(gè)例子，通過自動化的服務(wù)器配置可以避免在雪花服務(wù)器上排除故障和解決問題的工作量浪費(fèi)羽莺。這意味著 Dev 和 Ops 同樣可以理解一個(gè)服務(wù)器的變更是如何配置的了实昨。
營造 DevOps的文化：獎勵(lì)持續(xù)的“改進(jìn)冒險(xiǎn)”
“你無法直接改變文化，但你可以改變行為盐固，行為會變成文化荒给≌尚”
以上一切的發(fā)生，都需要從組織內(nèi)部做出改進(jìn)志电。但每個(gè)組織有每個(gè)組織的特性曙咽，改進(jìn)的方式和方法也不一樣。在這樣一個(gè)變動而開放的時(shí)代挑辆，沒有什么是絕對正確的例朱。每一個(gè)改進(jìn)的嘗試都是一場“改進(jìn)冒險(xiǎn)“。
在冒險(xiǎn)中鱼蝉，失敗并不可怕洒嗤，可怕的是失去了繼續(xù)改進(jìn)的動力。所以我們要鼓勵(lì)”改進(jìn)冒險(xiǎn)“的行為魁亦。
在很多組織中渔隶，變革的動力往往來自于上層的壓力。而在集權(quán)的組織中洁奈，一切權(quán)力都屬于上級管理者间唉。一切權(quán)力都屬于上級管理者的另外一個(gè)意思就是一切責(zé)任也都由上級承擔(dān)。這樣會在組織內(nèi)出現(xiàn)一個(gè)“承擔(dān)高風(fēng)險(xiǎn)和責(zé)任”的個(gè)人利术，而非共同分散風(fēng)險(xiǎn)的團(tuán)隊(duì)呈野。這是一個(gè)脆弱的組織結(jié)構(gòu)，而在這樣一個(gè)結(jié)構(gòu)下氯哮，往往會出現(xiàn)管理人員短視的投機(jī)行為际跪，而給整體企業(yè)帶來更大的風(fēng)險(xiǎn)。
而DevOps不僅僅能通過技術(shù)手段降低變更的風(fēng)險(xiǎn)喉钢，更是構(gòu)造一系列的實(shí)踐和制度來分散這種因高度集中化和集權(quán)化所帶來的風(fēng)險(xiǎn)姆打。
首先就是要充分給團(tuán)隊(duì)授權(quán)，讓團(tuán)隊(duì)能夠在有限的風(fēng)險(xiǎn)控制中開展改進(jìn)肠虽。改進(jìn)是不斷小步進(jìn)行的幔戏，如果步子太大，往往適得其反税课。
其次闲延，就是要有明確的目標(biāo)和度量方法『妫“沒有度量垒玲，改進(jìn)就無從談起”，改進(jìn)之前找颓，一定要設(shè)定好度量指標(biāo)合愈。以跟蹤并收集相關(guān)的數(shù)據(jù)。
最后，無論成功還是失敗佛析，都需要有產(chǎn)出益老，讓團(tuán)隊(duì)通過自我激勵(lì)的方式持續(xù)形成凝聚力。而不要因?yàn)橐淮蔚氖【腿P否定改進(jìn)寸莫。如同上文提到的捺萌，在一個(gè)對失敗不寬容的文化氛圍中。相較于承擔(dān)風(fēng)險(xiǎn)的改進(jìn)嘗試膘茎，人們往往傾向于不作為桃纯。
但是，對失敗寬容并不意味著不需要為失敗承擔(dān)責(zé)任披坏。而是要要從失敗中學(xué)習(xí)到經(jīng)驗(yàn)慈参，向成功的目標(biāo)不斷的努力。進(jìn)行下一場“改進(jìn)冒險(xiǎn)”刮萌。成功很可能是巧合，但失敗必然有原因娘扩，避免了那些失敗的原因着茸，就有很大的機(jī)會走向成功。
營造 DevOps文化的幾點(diǎn)提示
文化的改變是困難的琐旁，這并不是一個(gè)一蹴而就的行為涮阔。需要長期不斷堅(jiān)持才會有效果。而帶來的收益非常值得灰殴。
“文化是你獎勵(lì)和懲罰的行為”敬特，要對那些符合 DevOps 文化的行為給予獎勵(lì)，對于那些違反 DevOps 給予一定的警告或處罰牺陶。
以好的出發(fā)點(diǎn)推測人的行為而不是壞的出發(fā)點(diǎn)伟阔，這會破壞信任。
經(jīng)常質(zhì)疑制度是否有問題掰伸，而不是質(zhì)疑人是否有問題皱炉。有問題的行為一定是有問題的制度造成的。
不要吝惜你的表揚(yáng)和贊美狮鸭，但請保管好你的刻薄合搅，指責(zé)和冷嘲熱諷。
對失敗的寬容是強(qiáng)調(diào)反思和學(xué)習(xí)歧蕉，而不是懲罰灾部。
多想想自己能為他人做什么，而不是要求別人做什么惯退。
集體慶祝每一個(gè)成功赌髓，集體反思每一個(gè)失敗。
DevOps文化落地很難，但是收益巨大春弥。你仍然愿意去做嗎呛哟？
參考：
https://martinfowler.com/bliki/DevOpsCulture.html
http://itrevolution.com/devops-culture-part-1/
http://itrevolution.com/devops-culture-part-2/
https://blog.chef.io/2010/07/16/what-devops-means-to-me/
http://www.lieyunwang.com/archives/105338
https://theagileadmin.com/what-is-devops/
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
http://radify.io/blog/four-principles-of-devops/
https://dzone.com/articles/devops-devops-principles
https://devops.com/interconnect-2016-culture-matters/
https://jocelyngoldfein.com/culture-is-the-behavior-you-reward-and-punish-7e8e75c6543e#.lw8glaksp
https://pt.slideshare.net/jezhumble/devops-and-agile-release-management
