DevOps這個詞在近年來可謂大火。從2014年底我開始給一些企業(yè)做持續(xù)交付/DevOps相關的評估和咨詢，似乎每個企業(yè)都表示想要推行DevOps涩馆，或者說他們正在做DevOps又官。這把火蔓延的速度遠遠超過當年敏捷在IT行業(yè)的傳播。然而有些企業(yè)管理者對DevOps的認知讓我們意識到镣隶，由于各種有意或無意的因素极谊，這個概念不幸地成為了一個讓人困惑的buzz word……

什么是DevOps？

這里我想列出四種我們在市場上安岂、企業(yè)咨詢以及社區(qū)交流過程中接觸到的認知：

一些企業(yè)的運維部門找我們轻猖，說要搞DevOps。我請他們約開發(fā)部門的同事一起來溝通域那，卻得到類似于“不用管他們咙边，我們自己搞……”的回復。再問那打算搞啥呢次员？答案可能是“我們想談談自動化運維……”败许。

另一種認知是，敏捷宣言提出了“業(yè)務和開發(fā)要緊密協(xié)作淑蔚，擁抱變化市殷，將變化視為提升價值的機會而非麻煩∩采溃”那么DevOps則是將敏捷思想向運維延伸醋寝，通過開發(fā)和運維的緊密協(xié)作，讓交付的最后一公里也能擁抱變化带迟，兼顧吞吐量和穩(wěn)定性音羞。

進一步，有些企業(yè)提出了自運維“No-Ops”理念仓犬，讓運維的職能融入產品交付團隊嗅绰，由團隊自主、自助地完成部署發(fā)布婶肩，同時自己承擔線上問題支持等工作办陷，完全讓運維工作去中心化，實現“Who build it, who run it”律歼。

我們還看到民镜，一些咨詢或解決方案廠商的宣傳將DevOps刻畫成了一個全新的、從設計险毁、需求到發(fā)布運維端到端的研發(fā)體系制圈，似乎有了DevOps這把榔頭们童，軟件研發(fā)的各種問題都解決了。有了DevOps鲸鹦，苦逼的程序員們就迎來解放了...

作為企業(yè)管理者慧库，要在組織中引入DevOps并推動變革，首先要對DevOps的目標有清晰的認識馋嗜，并明確DevOps在自己企業(yè)的上下文中意味著什么齐板。我反對一些廠商將DevOps吹得太大，但這也絕不僅僅是運維單方面的目標葛菇。DevOps運動本質上是關于開發(fā)（含測試）和運維的協(xié)作甘磨，在“為用戶創(chuàng)造最大化價值”的一致目標下，讓軟件交付給用戶并獲得反饋的過程更加敏捷眯停。至于要不要將開發(fā)運維一體化济舆，則取決于具體產品的特征，在不同場景下可以有不同的協(xié)作模式莺债。

DevOps行業(yè)報告提出了兩個頂層的用于衡量IT組織效能的指標：吞吐量和穩(wěn)定性滋觉。在一些人看來，這兩個目標就像魚和熊掌不可兼得齐邦。追求交付吞吐量椎侠，就會帶來更大的不穩(wěn)定性和風險；而傳統(tǒng)運維管理以穩(wěn)定性為目標侄旬，就必然犧牲對變化的響應力肺蔚。之所以會有這樣的悲觀認知，是因為僅僅站在當前的時空看待問題儡羔，而無法超越自己的能力局限宣羊。企業(yè)管理者需要理解，進行DevOps轉型汰蜘，就是要超越自己的能力局限仇冯，超出當前的時空看問題，通過組織設計族操、過程改進和工程技術的提升讓組織能力上升到一個新的維度苛坚，我們完全可以做到同時提高IT交付的吞吐量和穩(wěn)定性，而不是在兩者之間取舍平衡色难。

然而泼舱，要突破自身的能力局限，這并非易事枷莉。下面談到的實施DevOps過程中的七大挑戰(zhàn)中的每一個都需要組織下決心投入娇昙，并耐心等待回報，沒有足夠的認知轉變和卓越領導力難以實現笤妙。

挑戰(zhàn)一：自動化測試投入不足冒掌，收益低

敏捷宣言自提出時噪裕，就已經將自動化測試作為敏捷、極限編程的核心實踐來強調股毫。然而這么多年過去了膳音，在組織中真正有效進行自動化測試的并不多，各種問題都在影響著組織和團隊對自動化測試的信心铃诬。

要想同時提升吞吐量和穩(wěn)定性祭陷，以自動化替代手工方式快速、頻繁的對軟件質量進行驗證是首要的手段氧急。如果說在以往談論敏捷開發(fā)的時候颗胡，自動化測試是對團隊的較高要求毫深，那么到了DevOps時代吩坝，這就是最基本的入門要求。毫不夸張的說哑蔫，如果軟件系統(tǒng)沒有一套較完善的自動化測試體系钉寝，就請不要談DevOps了。

最直接的問題是投入不足闸迷。很多管理者意識里是將自動化測試看做一項額外的嵌纲、可有可無的任務。他們關注的是短期的項目管理目標腥沽，而不是長期的產品持續(xù)演進逮走，往往只有進度壓力不大的時候才投入人力來做一做，或者單獨聘請一個團隊來補充測試用例今阳，然后離開师溅，而不是作為開發(fā)團隊交付軟件產品的一部分。這樣的模式很難產生一套長期有效的測試套件盾舌，反過來進一步削弱了管理者對其進行投入的信心墓臭。

另外常見的一些問題包括：

缺乏對自動化測試策略的正確認知，過多集中在界面上做測試妖谴，缺少單元測試和API測試窿锉。界面功能測試案例的開發(fā)和維護成本高，執(zhí)行速度慢膝舅；想想上千個案例全部執(zhí)行完可能需要跑上半天嗡载、一天，然后有幾十個案例因為環(huán)境或網絡問題而執(zhí)行失敗仍稀，卻不是因為代碼問題洼滚。結果是我們看到不少團隊從來沒有一次將所有案例全量執(zhí)行過，只能每次手動挑選一部分案例來跑琳轿。

缺乏一套獨立的自動化測試環(huán)境判沟，而是和手動測試共用一套環(huán)境耿芹。這種做法一方面會導致自動化測試和手動測試在資源和測試數據上相互影響，使得測試不穩(wěn)定挪哄；另一方面自動化測試過多依賴外部集成環(huán)境吧秕，缺少必要的依賴隔離，使得測試案例執(zhí)行不穩(wěn)定迹炼、執(zhí)行效率低砸彬。

自動化測試、手動測試和生產等各環(huán)境不一致斯入，使得自動化測試的結果不夠可信砂碉。

由測試人員或單獨的團隊來寫自動化測試，而不是讓開發(fā)人員寫刻两。這首先導致開發(fā)人員在設計和編碼時很少考慮為了更高效穩(wěn)定的自動化測試進行優(yōu)化增蹭，加大了測試開發(fā)的難度；其次測試人員必須等到開發(fā)基本編碼完成了才能開始寫測試案例磅摹，并且需要請開發(fā)人員講解API或界面元素的設計滋迈，這是一個低效的過程，浪費時間户誓。

沒有將自動化測試納入持續(xù)交付流水線自動化地頻繁執(zhí)行饼灿。我們看到不少團隊是在完成手動測試后、上線之前選擇性地執(zhí)行自動化測試案例來進行回歸帝美；這樣的用法沒有最大化其價值碍彭，對質量的反饋速度太慢。

要解決以上問題悼潭，并產生一套有效的自動化測試套件是一個巨大挑戰(zhàn)庇忌，需要管理者和團隊轉變質量意識；需要企業(yè)從項目化的管理轉向產品化的管理女责，人們才能真正長遠地去考慮對自動化測試的投資漆枚；需要影響業(yè)務人員在需求容量上的期望，為書寫自動化測試提供時間抵知。

挑戰(zhàn)二：高度集中的IT基礎設施服務

在傳統(tǒng)模式下墙基，像服務器申請、配置變更等IT服務是由高度集中的基礎設施管理團隊負責刷喜。產品交付團隊需要向集中的IT服務團隊提出申請残制；而該團隊往往承接著來自很多交付團隊的需求，于是只能將請求進行排隊依次處理掖疮，并且主要依靠手動處理初茶；結果是交付團隊不得不長時間等待，才能得到所需資源浊闪。這個過程中的手動操作恼布，使得經過一段時間后螺戳，基礎設施的配置變成了一個黑洞，沒人能夠說得清各個服務器之間的狀態(tài)差異折汞，當問題出現時需要耗費很長時間來進行分析定位倔幼。我把這樣的時代稱之為IT基礎設施服務的“農耕時代”。

IT基礎設施的管理要更加敏捷爽待，提高變更吞吐量并同時提高穩(wěn)定性损同，首先需要在基礎設施的管理上實現這四個目標：

標準化

腳本化

版本化

可視化

在此基礎上，基礎設施管理團隊不再排隊處理所有交付團隊的請求鸟款，而是專注于提供一個基于標準化膏燃、腳本化、版本化和可視化方式管理基礎設施的自助服務平臺何什；組織授權給各產品交付團隊利用平臺的能力组哩，以代碼化的方式隨時按需進行基礎設施的準備和變更「欢恚縮短等待時間的同時禁炒，因為進入生產環(huán)境的基礎設施變更已經以一致的方式在各個測試環(huán)境經過了驗證，減少了人為手動操作可能引入的錯誤和遺漏霍比，確保了各個環(huán)境的一致性；也讓前期的自動化和手動測試更加可信暴备，從而使得系統(tǒng)的穩(wěn)定性也得到提高悠瞬。這樣一個模式我稱之為IT基礎設施服務的“云時代”。

對企業(yè)來說涯捻，從這種基礎設施管理集中式控制向去中心化授權的轉變也是一個巨大挑戰(zhàn)浅妆。首先基礎設施自助服務平臺的建設需要投入；更重要的是障癌，能夠授權交付團隊依賴自動化方式凌外，而非人工來保障基礎設施配置的質量，本身就需要管理者的思想轉變涛浙。在我看來康辑，一些管理者傾向于依靠人來控制，而不信賴經過反復驗證的自動化過程轿亮，只有一個原因：人出了錯可以追責和懲罰疮薇，而自動化過程出了錯，不容易找到某個單一的人來擔責我注，總不至于懲罰機器按咒。

這里還有一個挑戰(zhàn)不得不提，這種轉變帶來了傳統(tǒng)運維模式下運維人員的技能要求轉變但骨，從以往手動的服務器操作励七，變成需要寫DSL智袭、需要會編程。這必然影響到一群人的職業(yè)發(fā)展掠抬，這會給變革帶來阻力俗孝；企業(yè)應當給這群人提供足夠的培訓镊讼，提供新的職業(yè)發(fā)展機會。

挑戰(zhàn)三：部署與發(fā)布未分離

在產品交付團隊追求頻繁變更、提升交付吞吐量的時候撩匕，即便進行了嚴格的同行評審、通過了完善的自動化測試宇弛、確保了基礎設施環(huán)境的一致性曙痘，但由于周期短、頻率高氛堕，要平衡投入產出的收益馏臭，在軟件進入生產環(huán)境時，還是有風險存在讼稚。因此一些管理者無論如何不敢在部署發(fā)布流程上進行放權括儒，減少審批控制。這種不安全感是來自傳統(tǒng)的發(fā)布過程缺少一種安全性策略锐想，也就是沒有將“部署”與“發(fā)布”分離帮寻。

“部署”和“發(fā)布”是兩個不同的詞，然而很多年里當提到將軟件最后發(fā)布給用戶使用時赠摇，兩個詞通常是混用的固逗。為什么呢？以往藕帜，我們將軟件發(fā)布給用戶的手段很單一烫罩，就是將軟件部署到生產環(huán)境跑起來，用戶就可以用了洽故，這兩個詞所代表的動作是同時完成的贝攒。

要讓發(fā)布環(huán)節(jié)變得更加安全，就需要將這兩個動作分離时甚“祝“部署”即是讓新的或修改的軟件安裝到目標環(huán)境上運行起來。這應當是一個技術決策撞秋，即是否執(zhí)行這個動作應當完全由技術團隊依靠對變更進行的同行評審和測試來決定长捧，隨時可以執(zhí)行。這個動作過程中吻贿，技術團隊重點關注的是：

部署過程自動化

版本更新過程對用戶無感知

能夠快速回滾串结。

而“發(fā)布”應當是一個業(yè)務決策，即允許業(yè)務和產品人員來控制新特性對用戶的可見性。首先對受控的小范圍用戶開放肌割，經過一段時間的反饋信息收集卧蜓，包括對系統(tǒng)穩(wěn)定性和用戶行為、喜好的觀察把敞，然后決定是否將其開放給更大范圍的用戶弥奸。如果系統(tǒng)存在質量或設計問題，可以很快關閉新特性奋早，或回退到舊的版本盛霎。在這個發(fā)布的過程中，交付團隊和業(yè)務人員重點關注的是：

系統(tǒng)穩(wěn)定性

用戶實驗反饋

要實現這樣的分離也是一個很大挑戰(zhàn)耽装。首先技術上愤炸，需要引入藍綠部署、金絲雀發(fā)布掉奄，以及特性開關等手段规个；但要讓每個團隊都自己去建立這樣一套機制成本太高，企業(yè)需要從平臺戰(zhàn)略的角度提供這樣一種便捷的能力來實現靈活可配置的在線受控實驗姓建；另一方面诞仓，這樣的分離意味著重新定義了在軟件部署發(fā)布過程中IT團隊和業(yè)務人員的職責，需要IT和業(yè)務的緊密協(xié)作速兔。

挑戰(zhàn)四：缺少自助式的持續(xù)交付平臺

DevOps不僅僅是關于運維的自動化墅拭，同時也是關于開發(fā)、測試到運維各個職能圍繞著每一次軟件變更的緊密協(xié)作憨栽。在這個過程中帜矾，開發(fā)關心的是代碼庫、編譯屑柔、構建；測試關心的是測試驗證和測試環(huán)境珍剑；運維關心的是部署與發(fā)布控制掸宛、監(jiān)控及支持等，各個環(huán)節(jié)的任務涉及到一系列工具構成的工具鏈招拙。然而在對很多客戶的調研中唧瘾，我們發(fā)現普遍存在的現狀是：

開發(fā)、測試和運維各自有自己的一套工具來完成自己關心的任務别凤，而這些工具既不相同饰序，也不相互關聯(lián)；軟件包在不同工具之間的轉移更多依靠人工來完成规哪；

由于工具上的割裂求豫，每個人并不清楚同一個變更在其它角色哪里到底發(fā)生了什么，也不關心；

由于從獲取代碼蝠嘉、編譯最疆、掃描、構建蚤告、測試努酸、部署、發(fā)布到獲得反饋的整個過程中涉及到很多工具的運用杜恰，很難有哪個團隊能夠靠自身力量在每一個環(huán)節(jié)都做得成熟获诈。

要在企業(yè)中實現DevOps，有一定規(guī)模的IT企業(yè)非常需要給產品交付團隊提供一個軟件持續(xù)交付平臺心褐，讓軟件從代碼提交構建到交付給用戶的整個過程得以在這個平臺上完成舔涎，包括所有自動化任務的配置和調度，支持信息可視化輻射檬寂，和內建一些必要的流程控制環(huán)節(jié)终抽，例如操作權限和信息審計等。這樣一個平臺應納入IT企業(yè)的戰(zhàn)略性平臺之一桶至，其價值我認為有幾點：

作為一個杠桿昼伴，在規(guī)模化的組織中撬動各個交付團隊的持續(xù)交付/DevOps工程技術能力镣屹，將其快速拉到一個基線圃郊，大大降低各團隊自己實施的成本；

通過統(tǒng)一的部署流水線將從代碼提交到交付給用戶的整個過程高度可視化出來女蜈，信息透明持舆；讓開發(fā)、測試和運維以高度一致的方式工作在同一個流水線上伪窖，真正建立起協(xié)作逸寓；

每一次的軟件變更在這個完整的流水線中得到充分的驗證，盡早發(fā)現有缺陷的變更覆山；而經過了完整驗證的變更可以隨時部署出去竹伸；

在組織級能夠將一些必不可少的控制環(huán)節(jié)內建到自動化過程中，比如質量保障過程簇宽、過程度量勋篓、權限控制及過程審計信息等，從而弱化很多傳統(tǒng)依靠人為檢查的管理流程魏割，實現精益敏捷的輕流程目標譬嚣。

我們已經明顯看到有不少互聯(lián)網公司，比如阿里钞它、騰訊在組織級提供類似這樣的交付平臺拜银，然而更多IT企業(yè)還沒有跟上殊鞭。

還有一個更重要的關鍵詞必須強調：“自助式”，這是平臺設計的前提盐股。我們在有些組織看到確實有類似的持續(xù)集成钱豁、持續(xù)交付平臺。然而對這個平臺的使用就如同前面提到的集中式IT基礎設施服務一樣疯汁，當交付團隊需要為新的應用或服務建立一套新的自動化構建任務牲尺，或需要修改現有配置時，必須向平臺的負責部門提出申請幌蚊，由集中式的團隊來幫助建立或修改配置谤碳。這些配置任務在集中式團隊排隊和等待，成為新的瓶頸溢豆。而產品交付團隊自身始終不具備自動化能力蜒简，每次變更配置都不得不等待，導致需要的自動化任務跟不上架構的變化漩仙，任務失敗后定位和解決問題很低效搓茬。最嚴重的是，團隊的開發(fā)队他、測試人員根本不關心持續(xù)集成的執(zhí)行和結果卷仑。這種模式下，平臺其實遠遠發(fā)揮不了它應有的作用麸折。

正確的做法是锡凝，平臺團隊只需要專注于提供自動化、自助式的持續(xù)交付平臺垢啼，將產品交付團隊當做自己的用戶窜锯，聽取使用反饋，持續(xù)演進芭析；平臺的設計必須要兼顧過程的標準化和流水線配置的靈活性锚扎；該團隊不負責為各產品配置構建任務和流水線。這個配置工作應完全由各交付團隊自己來完成馁启，必須要具備“在需要修改配置時隨時自己就可以修改”的能力工秩。若沒有該能力，組織就要提供培訓和賦能进统。

挑戰(zhàn)五：IT架構耦合度高

上圖左下方的這棟建筑，住著很多戶浪听。如果其中某一戶對自己房子的布局和功能不滿意螟碎，想要重新設計，這時一個房間的設計改動必然影響到其它住戶迹栓，甚至可能危機整棟建筑掉分。如果要想允許每一戶人隨時修改自己房子，不用太擔心危及整個系統(tǒng)，縮短整個改動的周期酥郭，就需要像圖中其它的小房子一樣华坦，彼此之間松耦合，靠簡單不从、標準的道路來連接惜姐。

我們的IT系統(tǒng)也是一樣，要實現DevOps的目標椿息，更快地響應業(yè)務變化歹袁、提高交付吞吐量，每個子系統(tǒng)的粒度就要小寝优，彼此之間松耦合条舔，各自可以獨立地進行測試和部署。很多企業(yè)多個系統(tǒng)因為耦合緊密不得不在同一時間點部署發(fā)布乏矾，為了確保每一次投產不出問題孟抗，需要投入大量人力來進行協(xié)調，投產部署過程要處理更大的復雜性钻心，也更容易引入質量問題凄硼。

另一方面的影響是，若單一系統(tǒng)規(guī)模大扔役、復雜性高帆喇、系統(tǒng)間耦合度高，就難以給予交付團隊更大授權亿胸、實現開發(fā)團隊自主運維坯钦。

DevOps轉型過程中的這一挑戰(zhàn)在于，企業(yè)必須對現有IT系統(tǒng)進行解耦侈玄，將目前很多代碼級依賴婉刀、數據庫級依賴、或業(yè)務上的緊密依賴進行解耦序仙，走向圍繞業(yè)務領域邊界建立的突颊、靠輕量級服務和消息集成的服務化架構，要從設計上使得相互依賴的服務之間在升級時做到前向兼容潘悼，這是一個困難且耗時的過程律秃；在這個過程中如果沒有恰當的架構演進策略，缺少正確的方法引導治唤，導致在服務拆分不合理棒动，或缺少與之配套的服務治理能力，結果可能適得其反宾添。這方面我們有過很多經驗教訓船惨。ThoughtWorks在實踐DevOps的過程中柜裸，往往就伴隨著大量的向微服務方向進行架構拆分和改造的工作，這一過程可能長達數年粱锐，逐步演進疙挺。但絕不能知難而退，投入必不可少怜浅。

挑戰(zhàn)六：職能化組織中的開發(fā)運維部門墻

在多年以前铐然，當傳統(tǒng)企業(yè)的業(yè)務發(fā)展對數字化的依賴程度還不高，當管理者將IT系統(tǒng)的開發(fā)視為一種耗費人力但又價值并不高的非核心能力時海雪，快速膨脹的軟件研發(fā)隊伍紛紛從原有的業(yè)務部門中拆分出來锦爵，成為了獨立的部門或信息技術子公司；隨著軟件系統(tǒng)的復雜性越來越高奥裸，在專業(yè)化险掀、流程化的考慮下，實現功能的開發(fā)湾宙、保障質量的測試和保障運行穩(wěn)定的運維按職責和技能不同被拆分成了各自獨立樟氢、相互制衡的部門。結果是各部門有了自己的目標侠鳄，彼此不同甚至相互沖突埠啃，都著眼于各自內部優(yōu)化；但很不幸地伟恶，在這個過程中企業(yè)的終極目標——最大化為用戶/客戶創(chuàng)造價值碴开，這個必須要所有職能作為一個有機的整體運作才能實現的目標——卻被弱化了。如下：

在這樣的組織設計中博秫，各部分在一致目標下的協(xié)作不足潦牛，而更加注重過程控制和相互制衡，要真正實現DevOps是不可能的挡育。舉幾個例子：

在給一些企業(yè)評估其持續(xù)交付和DevOps能力時巴碗，普遍的情況是開發(fā)完成的工作進入生產環(huán)境要經過冗長的審批過程，審批基于一大堆文檔即寒；然而事實是（不要欺騙自己）橡淆，那些并不了解產品細節(jié)和每一次變更細節(jié)的審批者，很少甚至從來沒有在審批過程中發(fā)現過潛藏的問題母赵，但這一過程卻嚴重拉長了新版本上線獲得用戶反饋的周期逸爵；可以說，如果開發(fā)團隊在提交文檔時凹嘲，某些文檔忘了修改痊银、還保持和上一次申請時一模一樣，估計那些審批者也發(fā)現不了（或者根本就不會細看）施绎；

另一個普遍的現實是前面提到過的溯革，開發(fā)、測試和運維各自有一套工具來完成自己關心的任務谷醉，而這些工具相互割裂致稀、重復建設，沒有協(xié)作俱尼。不一致的工作方式和工具既降低了交付吞吐量抖单，也給質量保障引入了更大風險。

讓軟件開發(fā)的最后一公里——運維環(huán)節(jié)變得更加敏捷和適應變化遇八，開發(fā)和運維職能的緊密協(xié)作是DevOps運動的最核心思想矛绘。要達到該目標，企業(yè)如何為開發(fā)和運維建立一致的目標刃永，通過協(xié)作而非制衡的方式來共同面對同時提升吞吐量和保障穩(wěn)定性的挑戰(zhàn)是企業(yè)實施DevOps最重要的命題货矮！組織需要下面這樣一種治理結構：

圍繞著提供給用戶的產品和服務，建立包括產品設計斯够、開發(fā)囚玫、測試和運維在內的產品交付團隊。這并不意味著組織一定要立即在匯報線的設置上做出改變读规，關鍵是如何設置目標和組織日常工作抓督！除了各業(yè)務產品，同時集中的IT運維服務部門也應走向產品化束亏，也就是從以往為各個業(yè)務產品提供運維支持铃在，轉向專注于為業(yè)務產品交付團隊提供支撐其交付的平臺，以及進行運維監(jiān)控碍遍、運營分析的平臺定铜；可能也從用戶支持統(tǒng)一體驗的角度出發(fā)，給各業(yè)務產品提供面向最終用戶統(tǒng)一的支持雀久、服務熱線和客戶服務渠道宿稀。

這種轉變對組織是很大的挑戰(zhàn)，涉及到多年形成的治理結構的改變赖捌。首先需要各級管理者思想上的改變祝沸，從基于不信任前提的控制型、分化制衡型管理思想越庇，轉變?yōu)榛谛湃吻疤岬姆招驼秩瘛f(xié)作型管理思想，這在ThoughtWorks提倡的適應性領導力中有深入探討卤唉。這種轉變從一開始涩惑，很難在組織大范圍開展，建議的是先建立特區(qū)桑驱，再逐步試點擴大竭恬，最后實現突破跛蛋；在轉變的過程中必然會涉及到部門職責范圍、績效考評痊硕、人才能力模型等深層次的轉變赊级。這種轉變需要組織管理者、轉型推動者發(fā)揮領導力岔绸，展現出變革的魄力和執(zhí)行力才能得以成功理逊。

挑戰(zhàn)七：缺少敏捷文化

前面談到的強職能化組織結構也深刻地影響著一個組織的文化。在與曾經咨詢過的一個客戶探討到如何進行DevOps轉型時盒揉，開發(fā)和運維部門坐在一起探討晋被。大家就運維流程如何改變、自動化能力如何建設等都沒有異議刚盈，然而自始至終無法突破的終極問題就是：無論我們如何改變羡洛，如果萬一生產環(huán)境出了問題，誰承擔責任扁掸？因為DevOps能力的建設需要一個過程翘县，開發(fā)團隊不敢承諾完全承擔責任；而運維因為弱化審批和控制力谴分，也認為不該為其承擔責任锈麸。最終不了了之。

我認為牺蹄，根本的問題出在文化忘伞，舊有的組織治理模式產生了各掃門前雪的官僚文化，沒有責任共擔沙兰，以及出現問題必然問責的文化氓奈。這種文化可能源自慣性的職能化思維，可能源自組織的績效考評和激勵制度鼎天。

現代關于“系統(tǒng)論”的研究已經在很多著作中強調舀奶，一個組織就是一個由人構成的復雜系統(tǒng)，組織中每一個人所能獲得的信息是有限的（包括最高管理者也是）斋射，每個人或團隊都只能基于自己有限的經驗育勺、有限的信息做出決策和行動。如果系統(tǒng)發(fā)生失敗罗岖，例如生產環(huán)境出現問題涧至，這必然是由于系統(tǒng)各個部分相互作用（從想法提出到軟件投產各個環(huán)節(jié)的相互作用、系統(tǒng)與其它系統(tǒng)間的相互作用）產生的結果桑包，對其中任何局部進行懲罰無非是尋找替罪羊南蓬，有害而無益。這時候組織真正應該做的，是相信每一個人都已經做出了最大努力赘方，將相關干系人拉到一起對問題的根因進行分析烧颖，找到能夠有效避免類似問題再次出現的解決方案，并確保該方案得到實施蒜焊，對其效果進行驗證倒信。

再舉一個例子，Petrik曾經在DevOpsDays上提到了一個DevOps的優(yōu)秀實踐：Chaos Monkey（混世魔猴）泳梆。這只自動化的猴子會每隔一段時間隨機將生產環(huán)境服務器關閉，以此來測試生產環(huán)境的快速恢復能力榜掌，促使各團隊提升系統(tǒng)的穩(wěn)定性优妙。我曾經和國內企業(yè)的開發(fā)、運維部門討論過這個實踐憎账，有趣的是無論開發(fā)還是運維都跳出來反對該實踐套硼，認為無法落地。如果沒有這只“猴子”胞皱，大家可以給領導講自己的系統(tǒng)很穩(wěn)定（只要沒出問題）邪意；然而這只“猴子”可能會隨時暴露出自己的系統(tǒng)并不像自己所宣稱的那樣穩(wěn)定，會降低自己在上級心目中的“有能力”印象反砌，隨之而來的可能就是問責雾鬼、懲罰。這樣的文化下宴树，大家真正關心的是如何給領導“表現”策菜，而不是在真正的系統(tǒng)穩(wěn)定性上追求卓越。

真正能夠實現DevOps的組織酒贬，我們認為需要具備下面這樣一些文化：

總結

無論是組織治理結構又憨、管理流程、工程技術能力還是文化特征锭吨，DevOps運動都和精益產品開發(fā)蠢莺、敏捷宣言所倡導的理念一致。我認為一個組織如果沒有充分經歷過敏捷文化的熏陶零如，也很難實現DevOps的目標躏将，充其量在自動化工具和技術能力上有所提升，收益很有限埠况。

因此我們不應當將DevOps作為一個孤立的運動去看待耸携，更不能僅僅從工具角度去實施，而是應當將DevOps作為企業(yè)在數字化進程中為追求創(chuàng)新和快速市場響應辕翰、為提升組織適應力所進行的精益敏捷組織轉型的一部分夺衍，這是一項系統(tǒng)工程。

盡管挑戰(zhàn)重重喜命，只要管理者首先從自身的管理思想出發(fā)做出改變沟沙，從組織小范圍開始河劝，將各種職能的人員聚攏到一起，設置共同的愿景和目標矛紫，打破束縛赎瞎，給予足夠授權，以緊密協(xié)作颊咬、責任共擔的方式共同面對挑戰(zhàn)务甥，就能取得成功。然后再將小范圍的經驗在更大的范圍逐步擴散喳篇，并適時地對企業(yè)深層次治理模式做出調整敞临，就能夠在整個企業(yè)范圍內產生積極影響力，帶來組織效能的巨大提升麸澜。

作者：ThoughtWorks中國

鏈接：http://www.reibang.com/p/9878c1d00dd9

來源：簡書

簡書著作權歸作者所有挺尿，任何形式的轉載都請聯(lián)系作者獲得授權并注明出處。