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