建站
咨詢
售后
建站咨詢
新聞中心
DevOps這個詞在近年來可謂大火。從2014年底我開始給一些企業(yè)做持續(xù)交付/DevOps相關的評估和咨詢，似乎每個企業(yè)都表示想要推行DevOps，或者說他們正在做DevOps。這把火蔓延的速度遠遠超過當年敏捷在IT行業(yè)的傳播。然而有些企業(yè)管理者對DevOps的認知讓我們意識到，由于各種有意或無意的因素，這個概念不幸地成為了一個讓人困惑的buzz word……
創(chuàng)新互聯(lián)公司服務項目包括鲅魚圈網(wǎng)站建設、鲅魚圈網(wǎng)站制作、鲅魚圈網(wǎng)頁制作以及鲅魚圈網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，鲅魚圈網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到鲅魚圈省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
什么是DevOps?
這里我想列出四種我們在市場上、企業(yè)咨詢以及社區(qū)交流過程中接觸到的認知：
- 一些企業(yè)的運維部門找我們，說要搞DevOps。我請他們約開發(fā)部門的同事一起來溝通，卻得到類似于“不用管他們，我們自己搞……”的回復。再問那打算搞啥呢?答案可能是“我們想談談自動化運維……”。
- 另一種認知是，敏捷宣言提出了“業(yè)務和開發(fā)要緊密協(xié)作，擁抱變化，將變化視為提升價值的機會而非麻煩。”那么DevOps則是將敏捷思想向運維延伸，通過開發(fā)和運維的緊密協(xié)作，讓交付的***一公里也能擁抱變化，兼顧吞吐量和穩(wěn)定性。
- 進一步，有些企業(yè)提出了自運維“No-Ops”理念，讓運維的職能融入產(chǎn)品交付團隊，由團隊自主、自助地完成部署發(fā)布，同時自己承擔線上問題支持等工作，完全讓運維工作去中心化，實現(xiàn)“Who build it, who run it”。
- 我們還看到，一些咨詢或解決方案廠商的宣傳將DevOps刻畫成了一個全新的、從設計、需求到發(fā)布運維端到端的研發(fā)體系，似乎有了DevOps這把榔頭，軟件研發(fā)的各種問題都解決了。有了DevOps，苦逼的程序員們就迎來解放了...
作為企業(yè)管理者，要在組織中引入DevOps并推動變革，首先要對DevOps的目標有清晰的認識，并明確DevOps在自己企業(yè)的上下文中意味著什么。我反對一些廠商將DevOps吹得太大，但這也絕不僅僅是運維單方面的目標。DevOps運動本質(zhì)上是關于開發(fā)(含測試)和運維的協(xié)作，在“為用戶創(chuàng)造***化價值”的一致目標下，讓軟件交付給用戶并獲得反饋的過程更加敏捷。至于要不要將開發(fā)運維一體化，則取決于具體產(chǎn)品的特征，在不同場景下可以有不同的協(xié)作模式。
DevOps行業(yè)報告提出了兩個頂層的用于衡量IT組織效能的指標：吞吐量和穩(wěn)定性。在一些人看來，這兩個目標就像魚和熊掌不可兼得。追求交付吞吐量，就會帶來更大的不穩(wěn)定性和風險;而傳統(tǒng)運維管理以穩(wěn)定性為目標，就必然犧牲對變化的響應力。之所以會有這樣的悲觀認知，是因為僅僅站在當前的時空看待問題，而無法超越自己的能力局限。企業(yè)管理者需要理解，進行DevOps轉(zhuǎn)型，就是要超越自己的能力局限，超出當前的時空看問題，通過組織設計、過程改進和工程技術的提升讓組織能力上升到一個新的維度，我們完全可以做到同時提高IT交付的吞吐量和穩(wěn)定性，而不是在兩者之間取舍平衡。
然而，要突破自身的能力局限，這并非易事。下面談到的實施DevOps過程中的七大挑戰(zhàn)中的每一個都需要組織下決心投入，并耐心等待回報，沒有足夠的認知轉(zhuǎn)變和卓越領導力難以實現(xiàn)。
挑戰(zhàn)一：自動化測試投入不足，收益低
敏捷宣言自提出時，就已經(jīng)將自動化測試作為敏捷、極限編程的核心實踐來強調(diào)。然而這么多年過去了，在組織中真正有效進行自動化測試的并不多，各種問題都在影響著組織和團隊對自動化測試的信心。
要想同時提升吞吐量和穩(wěn)定性，以自動化替代手工方式快速、頻繁的對軟件質(zhì)量進行驗證是首要的手段。如果說在以往談論敏捷開發(fā)的時候，自動化測試是對團隊的較高要求，那么到了DevOps時代，這就是最基本的入門要求。毫不夸張的說，如果軟件系統(tǒng)沒有一套較完善的自動化測試體系，就請不要談DevOps了。
最直接的問題是投入不足。很多管理者意識里是將自動化測試看做一項額外的、可有可無的任務。他們關注的是短期的項目管理目標，而不是長期的產(chǎn)品持續(xù)演進，往往只有進度壓力不大的時候才投入人力來做一做，或者單獨聘請一個團隊來補充測試用例，然后離開，而不是作為開發(fā)團隊交付軟件產(chǎn)品的一部分。這樣的模式很難產(chǎn)生一套長期有效的測試套件，反過來進一步削弱了管理者對其進行投入的信心。
另外常見的一些問題包括：
- 缺乏對自動化測試策略的正確認知，過多集中在界面上做測試，缺少單元測試和API測試。界面功能測試案例的開發(fā)和維護成本高，執(zhí)行速度慢;想想上千個案例全部執(zhí)行完可能需要跑上半天、一天，然后有幾十個案例因為環(huán)境或網(wǎng)絡問題而執(zhí)行失敗，卻不是因為代碼問題。結果是我們看到不少團隊從來沒有一次將所有案例全量執(zhí)行過，只能每次手動挑選一部分案例來跑。
- 缺乏一套獨立的自動化測試環(huán)境，而是和手動測試共用一套環(huán)境。這種做法一方面會導致自動化測試和手動測試在資源和測試數(shù)據(jù)上相互影響，使得測試不穩(wěn)定;另一方面自動化測試過多依賴外部集成環(huán)境，缺少必要的依賴隔離，使得測試案例執(zhí)行不穩(wěn)定、執(zhí)行效率低。
- 自動化測試、手動測試和生產(chǎn)等各環(huán)境不一致，使得自動化測試的結果不夠可信。
- 由測試人員或單獨的團隊來寫自動化測試，而不是讓開發(fā)人員寫。這首先導致開發(fā)人員在設計和編碼時很少考慮為了更高效穩(wěn)定的自動化測試進行優(yōu)化，加大了測試開發(fā)的難度;其次測試人員必須等到開發(fā)基本編碼完成了才能開始寫測試案例，并且需要請開發(fā)人員講解API或界面元素的設計，這是一個低效的過程，浪費時間。
- 沒有將自動化測試納入持續(xù)交付流水線自動化地頻繁執(zhí)行。我們看到不少團隊是在完成手動測試后、上線之前選擇性地執(zhí)行自動化測試案例來進行回歸;這樣的用法沒有***化其價值，對質(zhì)量的反饋速度太慢。
要解決以上問題，并產(chǎn)生一套有效的自動化測試套件是一個巨大挑戰(zhàn)，需要管理者和團隊轉(zhuǎn)變質(zhì)量意識;需要企業(yè)從項目化的管理轉(zhuǎn)向產(chǎn)品化的管理，人們才能真正長遠地去考慮對自動化測試的投資;需要影響業(yè)務人員在需求容量上的期望，為書寫自動化測試提供時間。
挑戰(zhàn)二：高度集中的IT基礎設施服務
在傳統(tǒng)模式下，像服務器申請、配置變更等IT服務是由高度集中的基礎設施管理團隊負責。產(chǎn)品交付團隊需要向集中的IT服務團隊提出申請;而該團隊往往承接著來自很多交付團隊的需求，于是只能將請求進行排隊依次處理，并且主要依靠手動處理;結果是交付團隊不得不長時間等待，才能得到所需資源。這個過程中的手動操作，使得經(jīng)過一段時間后，基礎設施的配置變成了一個黑洞，沒人能夠說得清各個服務器之間的狀態(tài)差異，當問題出現(xiàn)時需要耗費很長時間來進行分析定位。我把這樣的時代稱之為IT基礎設施服務的“農(nóng)耕時代”。
IT基礎設施的管理要更加敏捷，提高變更吞吐量并同時提高穩(wěn)定性，首先需要在基礎設施的管理上實現(xiàn)這四個目標：
- 標準化
- 腳本化
- 版本化
- 可視化
在此基礎上，基礎設施管理團隊不再排隊處理所有交付團隊的請求，而是專注于提供一個基于標準化、腳本化、版本化和可視化方式管理基礎設施的自助服務平臺;組織授權給各產(chǎn)品交付團隊利用平臺的能力，以代碼化的方式隨時按需進行基礎設施的準備和變更。縮短等待時間的同時，因為進入生產(chǎn)環(huán)境的基礎設施變更已經(jīng)以一致的方式在各個測試環(huán)境經(jīng)過了驗證，減少了人為手動操作可能引入的錯誤和遺漏，確保了各個環(huán)境的一致性;也讓前期的自動化和手動測試更加可信，從而使得系統(tǒng)的穩(wěn)定性也得到提高。這樣一個模式我稱之為IT基礎設施服務的“云時代”。
對企業(yè)來說，從這種基礎設施管理集中式控制向去中心化授權的轉(zhuǎn)變也是一個巨大挑戰(zhàn)。首先基礎設施自助服務平臺的建設需要投入;更重要的是，能夠授權交付團隊依賴自動化方式，而非人工來保障基礎設施配置的質(zhì)量，本身就需要管理者的思想轉(zhuǎn)變。在我看來，一些管理者傾向于依靠人來控制，而不信賴經(jīng)過反復驗證的自動化過程，只有一個原因：人出了錯可以追責和懲罰，而自動化過程出了錯，不容易找到某個單一的人來擔責，總不至于懲罰機器。
這里還有一個挑戰(zhàn)不得不提，這種轉(zhuǎn)變帶來了傳統(tǒng)運維模式下運維人員的技能要求轉(zhuǎn)變，從以往手動的服務器操作，變成需要寫DSL、需要會編程。這必然影響到一群人的職業(yè)發(fā)展，這會給變革帶來阻力;企業(yè)應當給這群人提供足夠的培訓，提供新的職業(yè)發(fā)展機會。
挑戰(zhàn)三：部署與發(fā)布未分離
在產(chǎn)品交付團隊追求頻繁變更、提升交付吞吐量的時候，即便進行了嚴格的同行評審、通過了完善的自動化測試、確保了基礎設施環(huán)境的一致性，但由于周期短、頻率高，要平衡投入產(chǎn)出的收益，在軟件進入生產(chǎn)環(huán)境時，還是有風險存在。因此一些管理者無論如何不敢在部署發(fā)布流程上進行放權，減少審批控制。這種不安全感是來自傳統(tǒng)的發(fā)布過程缺少一種安全性策略，也就是沒有將“部署”與“發(fā)布”分離。
“部署”和“發(fā)布”是兩個不同的詞，然而很多年里當提到將軟件***發(fā)布給用戶使用時，兩個詞通常是混用的。為什么呢?以往，我們將軟件發(fā)布給用戶的手段很單一，就是將軟件部署到生產(chǎn)環(huán)境跑起來，用戶就可以用了，這兩個詞所代表的動作是同時完成的。
要讓發(fā)布環(huán)節(jié)變得更加安全，就需要將這兩個動作分離?！安渴稹奔词亲屝碌幕蛐薷牡能浖惭b到目標環(huán)境上運行起來。這應當是一個技術決策，即是否執(zhí)行這個動作應當完全由技術團隊依靠對變更進行的同行評審和測試來決定，隨時可以執(zhí)行。這個動作過程中，技術團隊重點關注的是：
- 部署過程自動化
- 版本更新過程對用戶無感知
- 能夠快速回滾。
而“發(fā)布”應當是一個業(yè)務決策，即允許業(yè)務和產(chǎn)品人員來控制新特性對用戶的可見性。首先對受控的小范圍用戶開放，經(jīng)過一段時間的反饋信息收集，包括對系統(tǒng)穩(wěn)定性和用戶行為、喜好的觀察，然后決定是否將其開放給更大范圍的用戶。如果系統(tǒng)存在質(zhì)量或設計問題，可以很快關閉新特性，或回退到舊的版本。在這個發(fā)布的過程中，交付團隊和業(yè)務人員重點關注的是：
- 系統(tǒng)穩(wěn)定性
- 用戶實驗反饋
要實現(xiàn)這樣的分離也是一個很大挑戰(zhàn)。首先技術上，需要引入藍綠部署、金絲雀發(fā)布，以及特性開關等手段;但要讓每個團隊都自己去建立這樣一套機制成本太高，企業(yè)需要從平臺戰(zhàn)略的角度提供這樣一種便捷的能力來實現(xiàn)靈活可配置的在線受控實驗;另一方面，這樣的分離意味著重新定義了在軟件部署發(fā)布過程中IT團隊和業(yè)務人員的職責，需要IT和業(yè)務的緊密協(xié)作。
挑戰(zhàn)四：缺少自助式的持續(xù)交付平臺
DevOps不僅僅是關于運維的自動化，同時也是關于開發(fā)、測試到運維各個職能圍繞著每一次軟件變更的緊密協(xié)作。在這個過程中，開發(fā)關心的是代碼庫、編譯、構建;測試關心的是測試驗證和測試環(huán)境;運維關心的是部署與發(fā)布控制、監(jiān)控及支持等，各個環(huán)節(jié)的任務涉及到一系列工具構成的工具鏈。然而在對很多客戶的調(diào)研中，我們發(fā)現(xiàn)普遍存在的現(xiàn)狀是：
- 開發(fā)、測試和運維各自有自己的一套工具來完成自己關心的任務，而這些工具既不相同，也不相互關聯(lián);軟件包在不同工具之間的轉(zhuǎn)移更多依靠人工來完成;
- 由于工具上的割裂，每個人并不清楚同一個變更在其它角色哪里到底發(fā)生了什么，也不關心;
- 由于從獲取代碼、編譯、掃描、構建、測試、部署、發(fā)布到獲得反饋的整個過程中涉及到很多工具的運用，很難有哪個團隊能夠靠自身力量在每一個環(huán)節(jié)都做得成熟。
要在企業(yè)中實現(xiàn)DevOps，有一定規(guī)模的IT企業(yè)非常需要給產(chǎn)品交付團隊提供一個軟件持續(xù)交付平臺，讓軟件從代碼提交構建到交付給用戶的整個過程得以在這個平臺上完成，包括所有自動化任務的配置和調(diào)度，支持信息可視化輻射，和內(nèi)建一些必要的流程控制環(huán)節(jié)，例如操作權限和信息審計等。這樣一個平臺應納入IT企業(yè)的戰(zhàn)略性平臺之一，其價值我認為有幾點：
- 作為一個杠桿，在規(guī)模化的組織中撬動各個交付團隊的持續(xù)交付/DevOps工程技術能力，將其快速拉到一個基線，大大降低各團隊自己實施的成本;
- 通過統(tǒng)一的部署流水線將從代碼提交到交付給用戶的整個過程高度可視化出來，信息透明;讓開發(fā)、測試和運維以高度一致的方式工作在同一個流水線上，真正建立起協(xié)作;
- 每一次的軟件變更在這個完整的流水線中得到充分的驗證，盡早發(fā)現(xiàn)有缺陷的變更;而經(jīng)過了完整驗證的變更可以隨時部署出去;
- 在組織級能夠?qū)⒁恍┍夭豢缮俚目刂骗h(huán)節(jié)內(nèi)建到自動化過程中，比如質(zhì)量保障過程、過程度量、權限控制及過程審計信息等，從而弱化很多傳統(tǒng)依靠人為檢查的管理流程，實現(xiàn)精益敏捷的輕流程目標。
我們已經(jīng)明顯看到有不少互聯(lián)網(wǎng)公司，比如阿里、騰訊在組織級提供類似這樣的交付平臺，然而更多IT企業(yè)還沒有跟上。
還有一個更重要的關鍵詞必須強調(diào)：“自助式”，這是平臺設計的前提。我們在有些組織看到確實有類似的持續(xù)集成、持續(xù)交付平臺。然而對這個平臺的使用就如同前面提到的集中式IT基礎設施服務一樣，當交付團隊需要為新的應用或服務建立一套新的自動化構建任務，或需要修改現(xiàn)有配置時，必須向平臺的負責部門提出申請，由集中式的團隊來幫助建立或修改配置。這些配置任務在集中式團隊排隊和等待，成為新的瓶頸。而產(chǎn)品交付團隊自身始終不具備自動化能力，每次變更配置都不得不等待，導致需要的自動化任務跟不上架構的變化，任務失敗后定位和解決問題很低效。最嚴重的是，團隊的開發(fā)、測試人員根本不關心持續(xù)集成的執(zhí)行和結果。這種模式下，平臺其實遠遠發(fā)揮不了它應有的作用。
正確的做法是，平臺團隊只需要專注于提供自動化、自助式的持續(xù)交付平臺，將產(chǎn)品交付團隊當做自己的用戶，聽取使用反饋，持續(xù)演進;平臺的設計必須要兼顧過程的標準化和流水線配置的靈活性;該團隊不負責為各產(chǎn)品配置構建任務和流水線。這個配置工作應完全由各交付團隊自己來完成，必須要具備“在需要修改配置時隨時自己就可以修改”的能力。若沒有該能力，組織就要提供培訓和賦能。
挑戰(zhàn)五：IT架構耦合度高
上圖左下方的這棟建筑，住著很多戶。如果其中某一戶對自己房子的布局和功能不滿意，想要重新設計，這時一個房間的設計改動必然影響到其它住戶，甚至可能危機整棟建筑。如果要想允許每一戶人隨時修改自己房子，不用太擔心危及整個系統(tǒng)，縮短整個改動的周期，就需要像圖中其它的小房子一樣，彼此之間松耦合，靠簡單、標準的道路來連接。
我們的IT系統(tǒng)也是一樣，要實現(xiàn)DevOps的目標，更快地響應業(yè)務變化、提高交付吞吐量，每個子系統(tǒng)的粒度就要小，彼此之間松耦合，各自可以獨立地進行測試和部署。很多企業(yè)多個系統(tǒng)因為耦合緊密不得不在同一時間點部署發(fā)布，為了確保每一次投產(chǎn)不出問題，需要投入大量人力來進行協(xié)調(diào)，投產(chǎn)部署過程要處理更大的復雜性，也更容易引入質(zhì)量問題。
另一方面的影響是，若單一系統(tǒng)規(guī)模大、復雜性高、系統(tǒng)間耦合度高，就難以給予交付團隊更大授權、實現(xiàn)開發(fā)團隊自主運維。
DevOps轉(zhuǎn)型過程中的這一挑戰(zhàn)在于，企業(yè)必須對現(xiàn)有IT系統(tǒng)進行解耦，將目前很多代碼級依賴、數(shù)據(jù)庫級依賴、或業(yè)務上的緊密依賴進行解耦，走向圍繞業(yè)務領域邊界建立的、靠輕量級服務和消息集成的服務化架構，要從設計上使得相互依賴的服務之間在升級時做到前向兼容，這是一個困難且耗時的過程;在這個過程中如果沒有恰當?shù)募軜嬔葸M策略，缺少正確的方法引導，導致在服務拆分不合理，或缺少與之配套的服務治理能力，結果可能適得其反。這方面我們有過很多經(jīng)驗教訓。ThoughtWorks在實踐DevOps的過程中，往往就伴隨著大量的向微服務方向進行架構拆分和改造的工作，這一過程可能長達數(shù)年，逐步演進。但絕不能知難而退，投入必不可少。
挑戰(zhàn)六：職能化組織中的開發(fā)運維部門墻
在多年以前，當傳統(tǒng)企業(yè)的業(yè)務發(fā)展對數(shù)字化的依賴程度還不高，當管理者將IT系統(tǒng)的開發(fā)視為一種耗費人力但又價值并不高的非核心能力時，快速膨脹的軟件研發(fā)隊伍紛紛從原有的業(yè)務部門中拆分出來，成為了獨立的部門或信息技術子公司;隨著軟件系統(tǒng)的復雜性越來越高，在專業(yè)化、流程化的考慮下，實現(xiàn)功能的開發(fā)、保障質(zhì)量的測試和保障運行穩(wěn)定的運維按職責和技能不同被拆分成了各自獨立、相互制衡的部門。結果是各部門有了自己的目標，彼此不同甚至相互沖突，都著眼于各自內(nèi)部優(yōu)化;但很不幸地，在這個過程中企業(yè)的***目標——***化為用戶/客戶創(chuàng)造價值，這個必須要所有職能作為一個有機的整體運作才能實現(xiàn)的目標——卻被弱化了。如下：
在這樣的組織設計中，各部分在一致目標下的協(xié)作不足，而更加注重過程控制和相互制衡，要真正實現(xiàn)DevOps是不可能的。舉幾個例子：
在給一些企業(yè)評估其持續(xù)交付和DevOps能力時，普遍的情況是開發(fā)完成的工作進入生產(chǎn)環(huán)境要經(jīng)過冗長的審批過程，審批基于一大堆文檔;然而事實是(不要欺騙自己)，那些并不了解產(chǎn)品細節(jié)和每一次變更細節(jié)的審批者，很少甚至從來沒有在審批過程中發(fā)現(xiàn)過潛藏的問題，但這一過程卻嚴重拉長了新版本上線獲得用戶反饋的周期;可以說，如果開發(fā)團隊在提交文檔時，某些文檔忘了修改、還保持和上一次申請時一模一樣，估計那些審批者也發(fā)現(xiàn)不了(或者根本就不會細看)。
另一個普遍的現(xiàn)實是前面提到過的，開發(fā)、測試和運維各自有一套工具來完成自己關心的任務，而這些工具相互割裂、重復建設，沒有協(xié)作。不一致的工作方式和工具既降低了交付吞吐量，也給質(zhì)量保障引入了更大風險。
讓軟件開發(fā)的***一公里——運維環(huán)節(jié)變得更加敏捷和適應變化，開發(fā)和運維職能的緊密協(xié)作是DevOps運動的最核心思想。要達到該目標，企業(yè)如何為開發(fā)和運維建立一致的目標，通過協(xié)作而非制衡的方式來共同面對同時提升吞吐量和保障穩(wěn)定性的挑戰(zhàn)是企業(yè)實施DevOps最重要的***!組織需要下面這樣一種治理結構：
圍繞著提供給用戶的產(chǎn)品和服務，建立包括產(chǎn)品設計、開發(fā)、測試和運維在內(nèi)的產(chǎn)品交付團隊。這并不意味著組織一定要立即在匯報線的設置上做出改變，關鍵是如何設置目標和組織日常工作!除了各業(yè)務產(chǎn)品，同時集中的IT運維服務部門也應走向產(chǎn)品化，也就是從以往為各個業(yè)務產(chǎn)品提供運維支持，轉(zhuǎn)向?qū)Ｗ⒂跒闃I(yè)務產(chǎn)品交付團隊提供支撐其交付的平臺，以及進行運維監(jiān)控、運營分析的平臺;可能也從用戶支持統(tǒng)一體驗的角度出發(fā)，給各業(yè)務產(chǎn)品提供面向最終用戶統(tǒng)一的支持、服務熱線和客戶服務渠道。
這種轉(zhuǎn)變對組織是很大的挑戰(zhàn)，涉及到多年形成的治理結構的改變。首先需要各級管理者思想上的改變，從基于不信任前提的控制型、分化制衡型管理思想，轉(zhuǎn)變?yōu)榛谛湃吻疤岬姆招汀f(xié)作型管理思想，這在ThoughtWorks提倡的適應性領導力中有深入探討。這種轉(zhuǎn)變從一開始，很難在組織大范圍開展，建議的是先建立特區(qū)，再逐步試點擴大，***實現(xiàn)突破;在轉(zhuǎn)變的過程中必然會涉及到部門職責范圍、績效考評、人才能力模型等深層次的轉(zhuǎn)變。這種轉(zhuǎn)變需要組織管理者、轉(zhuǎn)型推動者發(fā)揮領導力，展現(xiàn)出變革的魄力和執(zhí)行力才能得以成功。
挑戰(zhàn)七：缺少敏捷文化
前面談到的強職能化組織結構也深刻地影響著一個組織的文化。在與曾經(jīng)咨詢過的一個客戶探討到如何進行DevOps轉(zhuǎn)型時，開發(fā)和運維部門坐在一起探討。大家就運維流程如何改變、自動化能力如何建設等都沒有異議，然而自始至終無法突破的***問題就是：無論我們?nèi)绾胃淖?，如果萬一生產(chǎn)環(huán)境出了問題，誰承擔責任?因為DevOps能力的建設需要一個過程，開發(fā)團隊不敢承諾完全承擔責任;而運維因為弱化審批和控制力，也認為不該為其承擔責任。最終不了了之。
我認為，根本的問題出在文化，舊有的組織治理模式產(chǎn)生了各掃門前雪的官僚文化，沒有責任共擔，以及出現(xiàn)問題必然問責的文化。這種文化可能源自慣性的職能化思維，可能源自組織的績效考評和激勵制度。
現(xiàn)代關于“系統(tǒng)論”的研究已經(jīng)在很多著作中強調(diào)，一個組織就是一個由人構成的復雜系統(tǒng)，組織中每一個人所能獲得的信息是有限的(包括***管理者也是)，每個人或團隊都只能基于自己有限的經(jīng)驗、有限的信息做出決策和行動。如果系統(tǒng)發(fā)生失敗，例如生產(chǎn)環(huán)境出現(xiàn)問題，這必然是由于系統(tǒng)各個部分相互作用(從想法提出到軟件投產(chǎn)各個環(huán)節(jié)的相互作用、系統(tǒng)與其它系統(tǒng)間的相互作用)產(chǎn)生的結果，對其中任何局部進行懲罰無非是尋找替罪羊，有害而無益。這時候組織真正應該做的，是相信每一個人都已經(jīng)做出了***努力，將相關干系人拉到一起對問題的根因進行分析，找到能夠有效避免類似問題再次出現(xiàn)的解決方案，并確保該方案得到實施，對其效果進行驗證。
再舉一個例子，Petrik曾經(jīng)在DevOpsDays上提到了一個DevOps的優(yōu)秀實踐：Chaos Monkey(混世魔猴)。這只自動化的猴子會每隔一段時間隨機將生產(chǎn)環(huán)境服務器關閉，以此來測試生產(chǎn)環(huán)境的快速恢復能力，促使各團隊提升系統(tǒng)的穩(wěn)定性。我曾經(jīng)和國內(nèi)企業(yè)的開發(fā)、運維部門討論過這個實踐，有趣的是無論開發(fā)還是運維都跳出來反對該實踐，認為無法落地。如果沒有這只“猴子”，大家可以給領導講自己的系統(tǒng)很穩(wěn)定(只要沒出問題);然而這只“猴子”可能會隨時暴露出自己的系統(tǒng)并不像自己所宣稱的那樣穩(wěn)定，會降低自己在上級心目中的“有能力”印象，隨之而來的可能就是問責、懲罰。這樣的文化下，大家真正關心的是如何給領導“表現(xiàn)”，而不是在真正的系統(tǒng)穩(wěn)定性上追求卓越。
真正能夠?qū)崿F(xiàn)DevOps的組織，我們認為需要具備下面這樣一些文化：
總結
無論是組織治理結構、管理流程、工程技術能力還是文化特征，DevOps運動都和精益產(chǎn)品開發(fā)、敏捷宣言所倡導的理念一致。我認為一個組織如果沒有充分經(jīng)歷過敏捷文化的熏陶，也很難實現(xiàn)DevOps的目標，充其量在自動化工具和技術能力上有所提升，收益很有限。
因此我們不應當將DevOps作為一個孤立的運動去看待，更不能僅僅從工具角度去實施，而是應當將DevOps作為企業(yè)在數(shù)字化進程中為追求創(chuàng)新和快速市場響應、為提升組織適應力所進行的精益敏捷組織轉(zhuǎn)型的一部分，這是一項系統(tǒng)工程。 盡管挑戰(zhàn)重重，只要管理者首先從自身的管理思想出發(fā)做出改變，從組織小范圍開始，將各種職能的人員聚攏到一起，設置共同的愿景和目標，打破束縛，給予足夠授權，以緊密協(xié)作、責任共擔的方式共同面對挑戰(zhàn)，就能取得成功。然后再將小范圍的經(jīng)驗在更大的范圍逐步擴散，并適時地對企業(yè)深層次治理模式做出調(diào)整，就能夠在整個企業(yè)范圍內(nèi)產(chǎn)生積極影響力，帶來組織效能的巨大提升。
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
分享名稱：企業(yè)實施DevOps的七大挑戰(zhàn)
分享地址：http://www.5511xx.com/article/cdchjcd.html
