DevOps這個(gè)詞在近年來(lái)可謂大火。從2014年底我開(kāi)始給一些企業(yè)做持續(xù)交付/DevOps相關(guān)的評(píng)估和咨詢呜呐，似乎每個(gè)企業(yè)都表示想要推行DevOps，或者說(shuō)他們正在做DevOps。這把火蔓延的速度遠(yuǎn)遠(yuǎn)超過(guò)當(dāng)年敏捷在IT行業(yè)的傳播恤煞。然而有些企業(yè)管理者對(duì)DevOps的認(rèn)知讓我們意識(shí)到趾撵，由于各種有意或無(wú)意的因素侄柔，這個(gè)概念不幸地成為了一個(gè)讓人困惑的buzz word……
什么是DevOps？
這里我想列出四種我們?cè)谑袌?chǎng)上占调、企業(yè)咨詢以及社區(qū)交流過(guò)程中接觸到的認(rèn)知：
一些企業(yè)的運(yùn)維部門找我們暂题，說(shuō)要搞DevOps。我請(qǐng)他們約開(kāi)發(fā)部門的同事一起來(lái)溝通究珊，卻得到類似于“不用管他們薪者，我們自己搞……”的回復(fù)。再問(wèn)那打算搞啥呢剿涮？答案可能是“我們想談?wù)勛詣?dòng)化運(yùn)維……”言津。
另一種認(rèn)知是，敏捷宣言提出了“業(yè)務(wù)和開(kāi)發(fā)要緊密協(xié)作取试，擁抱變化悬槽，將變化視為提升價(jià)值的機(jī)會(huì)而非麻煩∷才ǎ”那么DevOps則是將敏捷思想向運(yùn)維延伸陷谱，通過(guò)開(kāi)發(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)線上問(wèn)題支持等工作访雪，完全讓運(yùn)維工作去中心化，實(shí)現(xiàn)“Who build it, who run it”掂林。
我們還看到臣缀，一些咨詢或解決方案廠商的宣傳將DevOps刻畫(huà)成了一個(gè)全新的、從設(shè)計(jì)泻帮、需求到發(fā)布運(yùn)維端到端的研發(fā)體系精置，似乎有了DevOps這把榔頭，軟件研發(fā)的各種問(wèn)題都解決了锣杂。有了DevOps脂倦，苦逼的程序員們就迎來(lái)解放了...
作為企業(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)于開(kāi)發(fā)（含測(cè)試）和運(yùn)維的協(xié)作棋电，在“為用戶創(chuàng)造最大化價(jià)值”的一致目標(biāo)下，讓軟件交付給用戶并獲得反饋的過(guò)程更加敏捷苇侵。至于要不要將開(kāi)發(fā)運(yùn)維一體化离陶，則取決于具體產(chǎn)品的特征，在不同場(chǎng)景下可以有不同的協(xié)作模式衅檀。
DevOps行業(yè)報(bào)告提出了兩個(gè)頂層的用于衡量IT組織效能的指標(biāo)：吞吐量和穩(wěn)定性招刨。在一些人看來(lái)，這兩個(gè)目標(biāo)就像魚(yú)和熊掌不可兼得哀军。追求交付吞吐量沉眶，就會(huì)帶來(lái)更大的不穩(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í)空看待問(wèn)題猿推，而無(wú)法超越自己的能力局限片习。企業(yè)管理者需要理解，進(jìn)行DevOps轉(zhuǎn)型蹬叭，就是要超越自己的能力局限藕咏，超出當(dāng)前的時(shí)空看問(wèn)題，通過(guò)組織設(shè)計(jì)秽五、過(guò)程改進(jìn)和工程技術(shù)的提升讓組織能力上升到一個(gè)新的維度孽查，我們完全可以做到同時(shí)提高IT交付的吞吐量和穩(wěn)定性，而不是在兩者之間取舍平衡坦喘。
然而盲再，要突破自身的能力局限，這并非易事瓣铣。下面談到的實(shí)施DevOps過(guò)程中的七大挑戰(zhàn)中的每一個(gè)都需要組織下決心投入答朋，并耐心等待回報(bào)，沒(méi)有足夠的認(rèn)知轉(zhuǎn)變和卓越領(lǐng)導(dǎo)力難以實(shí)現(xiàn)棠笑。
挑戰(zhàn)一：自動(dòng)化測(cè)試投入不足梦碗，收益低
敏捷宣言自提出時(shí)，就已經(jīng)將自動(dòng)化測(cè)試作為敏捷、極限編程的核心實(shí)踐來(lái)強(qiáng)調(diào)叉弦。然而這么多年過(guò)去了丐一，在組織中真正有效進(jìn)行自動(dòng)化測(cè)試的并不多藻糖，各種問(wèn)題都在影響著組織和團(tuán)隊(duì)對(duì)自動(dòng)化測(cè)試的信心淹冰。
要想同時(shí)提升吞吐量和穩(wěn)定性，以自動(dòng)化替代手工方式快速巨柒、頻繁的對(duì)軟件質(zhì)量進(jìn)行驗(yàn)證是首要的手段樱拴。如果說(shuō)在以往談?wù)撁艚蓍_(kāi)發(fā)的時(shí)候，自動(dòng)化測(cè)試是對(duì)團(tuán)隊(duì)的較高要求洋满，那么到了DevOps時(shí)代晶乔，這就是最基本的入門要求。毫不夸張的說(shuō)牺勾，如果軟件系統(tǒng)沒(méi)有一套較完善的自動(dòng)化測(cè)試體系正罢，就請(qǐng)不要談DevOps了。
最直接的問(wèn)題是投入不足驻民。很多管理者意識(shí)里是將自動(dòng)化測(cè)試看做一項(xiàng)額外的翻具、可有可無(wú)的任務(wù)。他們關(guān)注的是短期的項(xiàng)目管理目標(biāo)回还，而不是長(zhǎng)期的產(chǎn)品持續(xù)演進(jìn)裆泳，往往只有進(jìn)度壓力不大的時(shí)候才投入人力來(lái)做一做，或者單獨(dú)聘請(qǐng)一個(gè)團(tuán)隊(duì)來(lái)補(bǔ)充測(cè)試用例柠硕，然后離開(kāi)工禾，而不是作為開(kāi)發(fā)團(tuán)隊(duì)交付軟件產(chǎn)品的一部分。這樣的模式很難產(chǎn)生一套長(zhǎng)期有效的測(cè)試套件蝗柔，反過(guò)來(lái)進(jìn)一步削弱了管理者對(duì)其進(jìn)行投入的信心闻葵。
另外常見(jiàn)的一些問(wèn)題包括：
-
缺乏對(duì)自動(dòng)化測(cè)試策略的正確認(rèn)知，過(guò)多集中在界面上做測(cè)試癣丧，缺少單元測(cè)試和API測(cè)試笙隙。界面功能測(cè)試案例的開(kāi)發(fā)和維護(hù)成本高，執(zhí)行速度慢坎缭；想想上千個(gè)案例全部執(zhí)行完可能需要跑上半天竟痰、一天，然后有幾十個(gè)案例因?yàn)榄h(huán)境或網(wǎng)絡(luò)問(wèn)題而執(zhí)行失敗掏呼，卻不是因?yàn)榇a問(wèn)題坏快。結(jié)果是我們看到不少團(tuán)隊(duì)從來(lái)沒(méi)有一次將所有案例全量執(zhí)行過(guò)，只能每次手動(dòng)挑選一部分案例來(lái)跑憎夷。
缺乏一套獨(dú)立的自動(dòng)化測(cè)試環(huán)境莽鸿，而是和手動(dòng)測(cè)試共用一套環(huán)境。這種做法一方面會(huì)導(dǎo)致自動(dòng)化測(cè)試和手動(dòng)測(cè)試在資源和測(cè)試數(shù)據(jù)上相互影響，使得測(cè)試不穩(wěn)定祥得；另一方面自動(dòng)化測(cè)試過(guò)多依賴外部集成環(huán)境兔沃，缺少必要的依賴隔離，使得測(cè)試案例執(zhí)行不穩(wěn)定级及、執(zhí)行效率低乒疏。
自動(dòng)化測(cè)試、手動(dòng)測(cè)試和生產(chǎn)等各環(huán)境不一致饮焦，使得自動(dòng)化測(cè)試的結(jié)果不夠可信怕吴。
由測(cè)試人員或單獨(dú)的團(tuán)隊(duì)來(lái)寫自動(dòng)化測(cè)試，而不是讓開(kāi)發(fā)人員寫县踢。這首先導(dǎo)致開(kāi)發(fā)人員在設(shè)計(jì)和編碼時(shí)很少考慮為了更高效穩(wěn)定的自動(dòng)化測(cè)試進(jìn)行優(yōu)化转绷，加大了測(cè)試開(kāi)發(fā)的難度；其次測(cè)試人員必須等到開(kāi)發(fā)基本編碼完成了才能開(kāi)始寫測(cè)試案例硼啤，并且需要請(qǐng)開(kāi)發(fā)人員講解API或界面元素的設(shè)計(jì)议经，這是一個(gè)低效的過(guò)程，浪費(fèi)時(shí)間谴返。
沒(méi)有將自動(dòng)化測(cè)試納入持續(xù)交付流水線自動(dòng)化地頻繁執(zhí)行煞肾。我們看到不少團(tuán)隊(duì)是在完成手動(dòng)測(cè)試后、上線之前選擇性地執(zhí)行自動(dòng)化測(cè)試案例來(lái)進(jìn)行回歸亏镰；這樣的用法沒(méi)有最大化其價(jià)值扯旷，對(duì)質(zhì)量的反饋速度太慢。
要解決以上問(wèn)題索抓，并產(chǎn)生一套有效的自動(dòng)化測(cè)試套件是一個(gè)巨大挑戰(zhàn)钧忽，需要管理者和團(tuán)隊(duì)轉(zhuǎn)變質(zhì)量意識(shí)；需要企業(yè)從項(xiàng)目化的管理轉(zhuǎn)向產(chǎn)品化的管理逼肯，人們才能真正長(zhǎng)遠(yuǎn)地去考慮對(duì)自動(dòng)化測(cè)試的投資耸黑；需要影響業(yè)務(wù)人員在需求容量上的期望，為書(shū)寫自動(dòng)化測(cè)試提供時(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ì)往往承接著來(lái)自很多交付團(tuán)隊(duì)的需求，于是只能將請(qǐng)求進(jìn)行排隊(duì)依次處理搜锰，并且主要依靠手動(dòng)處理伴郁；結(jié)果是交付團(tuán)隊(duì)不得不長(zhǎng)時(shí)間等待，才能得到所需資源蛋叼。這個(gè)過(guò)程中的手動(dòng)操作焊傅，使得經(jīng)過(guò)一段時(shí)間后剂陡，基礎(chǔ)設(shè)施的配置變成了一個(gè)黑洞，沒(méi)人能夠說(shuō)得清各個(gè)服務(wù)器之間的狀態(tài)差異狐胎，當(dāng)問(wèn)題出現(xiàn)時(shí)需要耗費(fèi)很長(zhǎng)時(shí)間來(lái)進(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)備和變更带射⊥妫縮短等待時(shí)間的同時(shí)，因?yàn)檫M(jìn)入生產(chǎn)環(huán)境的基礎(chǔ)設(shè)施變更已經(jīng)以一致的方式在各個(gè)測(cè)試環(huán)境經(jīng)過(guò)了驗(yàn)證窟社，減少了人為手動(dòng)操作可能引入的錯(cuò)誤和遺漏券勺，確保了各個(gè)環(huán)境的一致性；也讓前期的自動(dòng)化和手動(dòng)測(cè)試更加可信灿里，從而使得系統(tǒng)的穩(wěn)定性也得到提高关炼。這樣一個(gè)模式我稱之為IT基礎(chǔ)設(shè)施服務(wù)的“云時(shí)代”。
對(duì)企業(yè)來(lái)說(shuō)匣吊，從這種基礎(chǔ)設(shè)施管理集中式控制向去中心化授權(quán)的轉(zhuǎn)變也是一個(gè)巨大挑戰(zhàn)儒拂。首先基礎(chǔ)設(shè)施自助服務(wù)平臺(tái)的建設(shè)需要投入；更重要的是色鸳，能夠授權(quán)交付團(tuán)隊(duì)依賴自動(dòng)化方式社痛，而非人工來(lái)保障基礎(chǔ)設(shè)施配置的質(zhì)量，本身就需要管理者的思想轉(zhuǎn)變命雀。在我看來(lái)蒜哀，一些管理者傾向于依靠人來(lái)控制，而不信賴經(jīng)過(guò)反復(fù)驗(yàn)證的自動(dòng)化過(guò)程吏砂，只有一個(gè)原因：人出了錯(cuò)可以追責(zé)和懲罰撵儿，而自動(dòng)化過(guò)程出了錯(cuò)，不容易找到某個(gè)單一的人來(lái)?yè)?dān)責(zé)狐血，總不至于懲罰機(jī)器淀歇。
這里還有一個(gè)挑戰(zhàn)不得不提，這種轉(zhuǎn)變帶來(lái)了傳統(tǒng)運(yùn)維模式下運(yùn)維人員的技能要求轉(zhuǎn)變氛雪，從以往手動(dòng)的服務(wù)器操作房匆，變成需要寫DSL、需要會(huì)編程。這必然影響到一群人的職業(yè)發(fā)展浴鸿，這會(huì)給變革帶來(lái)阻力井氢；企業(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)審掸哑、通過(guò)了完善的自動(dòng)化測(cè)試约急、確保了基礎(chǔ)設(shè)施環(huán)境的一致性，但由于周期短苗分、頻率高厌蔽，要平衡投入產(chǎn)出的收益，在軟件進(jìn)入生產(chǎn)環(huán)境時(shí)摔癣，還是有風(fēng)險(xiǎn)存在奴饮。因此一些管理者無(wú)論如何不敢在部署發(fā)布流程上進(jìn)行放權(quán)，減少審批控制择浊。這種不安全感是來(lái)自傳統(tǒng)的發(fā)布過(guò)程缺少一種安全性策略戴卜，也就是沒(méi)有將“部署”與“發(fā)布”分離。
“部署”和“發(fā)布”是兩個(gè)不同的詞琢岩，然而很多年里當(dāng)提到將軟件最后發(fā)布給用戶使用時(shí)投剥，兩個(gè)詞通常是混用的。為什么呢担孔？以往江锨，我們將軟件發(fā)布給用戶的手段很單一，就是將軟件部署到生產(chǎn)環(huán)境跑起來(lái)攒磨，用戶就可以用了泳桦，這兩個(gè)詞所代表的動(dòng)作是同時(shí)完成的。
要讓發(fā)布環(huán)節(jié)變得更加安全娩缰，就需要將這兩個(gè)動(dòng)作分離灸撰。“部署”即是讓新的或修改的軟件安裝到目標(biāo)環(huán)境上運(yùn)行起來(lái)拼坎。這應(yīng)當(dāng)是一個(gè)技術(shù)決策浮毯，即是否執(zhí)行這個(gè)動(dòng)作應(yīng)當(dāng)完全由技術(shù)團(tuán)隊(duì)依靠對(duì)變更進(jìn)行的同行評(píng)審和測(cè)試來(lái)決定，隨時(shí)可以執(zhí)行泰鸡。這個(gè)動(dòng)作過(guò)程中债蓝，技術(shù)團(tuán)隊(duì)重點(diǎn)關(guān)注的是：
- 部署過(guò)程自動(dòng)化
- 版本更新過(guò)程對(duì)用戶無(wú)感知
- 能夠快速回滾。
而“發(fā)布”應(yīng)當(dāng)是一個(gè)業(yè)務(wù)決策盛龄，即允許業(yè)務(wù)和產(chǎn)品人員來(lái)控制新特性對(duì)用戶的可見(jiàn)性饰迹。首先對(duì)受控的小范圍用戶開(kāi)放芳誓，經(jīng)過(guò)一段時(shí)間的反饋信息收集，包括對(duì)系統(tǒng)穩(wěn)定性和用戶行為啊鸭、喜好的觀察锹淌，然后決定是否將其開(kāi)放給更大范圍的用戶。如果系統(tǒng)存在質(zhì)量或設(shè)計(jì)問(wèn)題赠制，可以很快關(guān)閉新特性赂摆，或回退到舊的版本。在這個(gè)發(fā)布的過(guò)程中钟些，交付團(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ā)布汪拥，以及特性開(kāi)關(guān)等手段；但要讓每個(gè)團(tuán)隊(duì)都自己去建立這樣一套機(jī)制成本太高抚垃，企業(yè)需要從平臺(tái)戰(zhàn)略的角度提供這樣一種便捷的能力來(lái)實(shí)現(xiàn)靈活可配置的在線受控實(shí)驗(yàn)喷楣；另一方面趟大，這樣的分離意味著重新定義了在軟件部署發(fā)布過(guò)程中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)于開(kāi)發(fā)罕伯、測(cè)試到運(yùn)維各個(gè)職能圍繞著每一次軟件變更的緊密協(xié)作。在這個(gè)過(guò)程中叽讳，開(kāi)發(fā)關(guān)心的是代碼庫(kù)追他、編譯、構(gòu)建岛蚤；測(cè)試關(guān)心的是測(cè)試驗(yàn)證和測(cè)試環(huán)境邑狸；運(yùn)維關(guān)心的是部署與發(fā)布控制、監(jiān)控及支持等涤妒，各個(gè)環(huán)節(jié)的任務(wù)涉及到一系列工具構(gòu)成的工具鏈单雾。然而在對(duì)很多客戶的調(diào)研中，我們發(fā)現(xiàn)普遍存在的現(xiàn)狀是：
- 開(kāi)發(fā)她紫、測(cè)試和運(yùn)維各自有自己的一套工具來(lái)完成自己關(guān)心的任務(wù)硅堆，而這些工具既不相同，也不相互關(guān)聯(lián)贿讹；軟件包在不同工具之間的轉(zhuǎn)移更多依靠人工來(lái)完成渐逃；
- 由于工具上的割裂，每個(gè)人并不清楚同一個(gè)變更在其它角色哪里到底發(fā)生了什么民褂，也不關(guān)心茄菊；
- 由于從獲取代碼疯潭、編譯、掃描面殖、構(gòu)建袁勺、測(cè)試、部署畜普、發(fā)布到獲得反饋的整個(gè)過(guò)程中涉及到很多工具的運(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è)過(guò)程得以在這個(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í)施的成本码撰；
- 通過(guò)統(tǒng)一的部署流水線將從代碼提交到交付給用戶的整個(gè)過(guò)程高度可視化出來(lái)渗柿，信息透明；讓開(kāi)發(fā)脖岛、測(cè)試和運(yùn)維以高度一致的方式工作在同一個(gè)流水線上朵栖，真正建立起協(xié)作；
- 每一次的軟件變更在這個(gè)完整的流水線中得到充分的驗(yàn)證柴梆，盡早發(fā)現(xiàn)有缺陷的變更陨溅；而經(jīng)過(guò)了完整驗(yàn)證的變更可以隨時(shí)部署出去；
- 在組織級(jí)能夠?qū)⒁恍┍夭豢缮俚目刂骗h(huán)節(jié)內(nèi)建到自動(dòng)化過(guò)程中绍在，比如質(zhì)量保障過(guò)程门扇、過(guò)程度量、權(quán)限控制及過(guò)程審計(jì)信息等揣苏，從而弱化很多傳統(tǒng)依靠人為檢查的管理流程悯嗓，實(shí)現(xiàn)精益敏捷的輕流程目標(biāo)。
我們已經(jīng)明顯看到有不少互聯(lián)網(wǎng)公司卸察，比如阿里脯厨、騰訊在組織級(jí)提供類似這樣的交付平臺(tái)，然而更多IT企業(yè)還沒(méi)有跟上坑质。
還有一個(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ì)來(lái)幫助建立或修改配置。這些配置任務(wù)在集中式團(tuán)隊(duì)排隊(duì)和等待红淡，成為新的瓶頸不狮。而產(chǎn)品交付團(tuán)隊(duì)自身始終不具備自動(dòng)化能力，每次變更配置都不得不等待在旱，導(dǎo)致需要的自動(dòng)化任務(wù)跟不上架構(gòu)的變化摇零，任務(wù)失敗后定位和解決問(wèn)題很低效。最嚴(yán)重的是桶蝎，團(tuán)隊(duì)的開(kāi)發(fā)驻仅、測(cè)試人員根本不關(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)做自己的用戶，聽(tīng)取使用反饋竹揍，持續(xù)演進(jìn)；平臺(tái)的設(shè)計(jì)必須要兼顧過(guò)程的標(biāo)準(zhǔn)化和流水線配置的靈活性邪铲；該團(tuán)隊(duì)不負(fù)責(zé)為各產(chǎn)品配置構(gòu)建任務(wù)和流水線芬位。這個(gè)配置工作應(yīng)完全由各交付團(tuán)隊(duì)自己來(lái)完成，必須要具備“在需要修改配置時(shí)隨時(shí)自己就可以修改”的能力带到。若沒(méi)有該能力昧碉，組織就要提供培訓(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)的周期哎垦，就需要像圖中其它的小房子一樣，彼此之間松耦合恃疯，靠簡(jiǎn)單漏设、標(biāo)準(zhǔn)的道路來(lái)連接。
我們的IT系統(tǒng)也是一樣今妄，要實(shí)現(xiàn)DevOps的目標(biāo)郑口，更快地響應(yīng)業(yè)務(wù)變化糟描、提高交付吞吐量擎场，每個(gè)子系統(tǒng)的粒度就要小，彼此之間松耦合揪阿，各自可以獨(dú)立地進(jìn)行測(cè)試和部署雁仲。很多企業(yè)多個(gè)系統(tǒng)因?yàn)轳詈暇o密不得不在同一時(shí)間點(diǎn)部署發(fā)布仔夺，為了確保每一次投產(chǎn)不出問(wèn)題，需要投入大量人力來(lái)進(jìn)行協(xié)調(diào)攒砖，投產(chǎn)部署過(guò)程要處理更大的復(fù)雜性缸兔，也更容易引入質(zhì)量問(wèn)題。
另一方面的影響是吹艇，若單一系統(tǒng)規(guī)模大惰蜜、復(fù)雜性高、系統(tǒng)間耦合度高受神，就難以給予交付團(tuán)隊(duì)更大授權(quán)抛猖、實(shí)現(xiàn)開(kāi)發(fā)團(tuán)隊(duì)自主運(yùn)維。
DevOps轉(zhuǎn)型過(guò)程中的這一挑戰(zhàn)在于鼻听，企業(yè)必須對(duì)現(xiàn)有IT系統(tǒng)進(jìn)行解耦财著，將目前很多代碼級(jí)依賴、數(shù)據(jù)庫(kù)級(jí)依賴撑碴、或業(yè)務(wù)上的緊密依賴進(jìn)行解耦撑教，走向圍繞業(yè)務(wù)領(lǐng)域邊界建立的、靠輕量級(jí)服務(wù)和消息集成的服務(wù)化架構(gòu)醉拓，要從設(shè)計(jì)上使得相互依賴的服務(wù)之間在升級(jí)時(shí)做到前向兼容伟姐，這是一個(gè)困難且耗時(shí)的過(guò)程；在這個(gè)過(guò)程中如果沒(méi)有恰當(dāng)?shù)募軜?gòu)演進(jìn)策略亿卤，缺少正確的方法引導(dǎo)愤兵，導(dǎo)致在服務(wù)拆分不合理，或缺少與之配套的服務(wù)治理能力排吴，結(jié)果可能適得其反秆乳。這方面我們有過(guò)很多經(jīng)驗(yàn)教訓(xùn)。ThoughtWorks在實(shí)踐DevOps的過(guò)程中傍念，往往就伴隨著大量的向微服務(wù)方向進(jìn)行架構(gòu)拆分和改造的工作矫夷，這一過(guò)程可能長(zhǎng)達(dá)數(shù)年葛闷，逐步演進(jìn)。但絕不能知難而退双藕，投入必不可少淑趾。
挑戰(zhàn)六：職能化組織中的開(kāi)發(fā)運(yùn)維部門墻
在多年以前，當(dāng)傳統(tǒng)企業(yè)的業(yè)務(wù)發(fā)展對(duì)數(shù)字化的依賴程度還不高忧陪，當(dāng)管理者將IT系統(tǒng)的開(kāi)發(fā)視為一種耗費(fèi)人力但又價(jià)值并不高的非核心能力時(shí)扣泊，快速膨脹的軟件研發(fā)隊(duì)伍紛紛從原有的業(yè)務(wù)部門中拆分出來(lái)，成為了獨(dú)立的部門或信息技術(shù)子公司嘶摊；隨著軟件系統(tǒng)的復(fù)雜性越來(lái)越高延蟹，在專業(yè)化、流程化的考慮下叶堆，實(shí)現(xiàn)功能的開(kāi)發(fā)阱飘、保障質(zhì)量的測(cè)試和保障運(yùn)行穩(wěn)定的運(yùn)維按職責(zé)和技能不同被拆分成了各自獨(dú)立、相互制衡的部門虱颗。結(jié)果是各部門有了自己的目標(biāo)沥匈，彼此不同甚至相互沖突，都著眼于各自內(nèi)部?jī)?yōu)化忘渔；但很不幸地高帖，在這個(gè)過(guò)程中企業(yè)的終極目標(biāo)——最大化為用戶/客戶創(chuàng)造價(jià)值，這個(gè)必須要所有職能作為一個(gè)有機(jī)的整體運(yùn)作才能實(shí)現(xiàn)的目標(biāo)——卻被弱化了畦粮。如下：
在這樣的組織設(shè)計(jì)中散址，各部分在一致目標(biāo)下的協(xié)作不足，而更加注重過(guò)程控制和相互制衡宣赔，要真正實(shí)現(xiàn)DevOps是不可能的预麸。舉幾個(gè)例子：
在給一些企業(yè)評(píng)估其持續(xù)交付和DevOps能力時(shí)，普遍的情況是開(kāi)發(fā)完成的工作進(jìn)入生產(chǎn)環(huán)境要經(jīng)過(guò)冗長(zhǎng)的審批過(guò)程拉背，審批基于一大堆文檔师崎；然而事實(shí)是（不要欺騙自己），那些并不了解產(chǎn)品細(xì)節(jié)和每一次變更細(xì)節(jié)的審批者椅棺，很少甚至從來(lái)沒(méi)有在審批過(guò)程中發(fā)現(xiàn)過(guò)潛藏的問(wèn)題，但這一過(guò)程卻嚴(yán)重拉長(zhǎng)了新版本上線獲得用戶反饋的周期齐蔽；可以說(shuō)两疚，如果開(kāi)發(fā)團(tuán)隊(duì)在提交文檔時(shí)，某些文檔忘了修改含滴、還保持和上一次申請(qǐng)時(shí)一模一樣诱渤，估計(jì)那些審批者也發(fā)現(xiàn)不了（或者根本就不會(huì)細(xì)看）；
另一個(gè)普遍的現(xiàn)實(shí)是前面提到過(guò)的谈况，開(kāi)發(fā)勺美、測(cè)試和運(yùn)維各自有一套工具來(lái)完成自己關(guān)心的任務(wù)递胧，而這些工具相互割裂、重復(fù)建設(shè)赡茸，沒(méi)有協(xié)作缎脾。不一致的工作方式和工具既降低了交付吞吐量，也給質(zhì)量保障引入了更大風(fēng)險(xiǎn)占卧。
讓軟件開(kāi)發(fā)的最后一公里——運(yùn)維環(huán)節(jié)變得更加敏捷和適應(yīng)變化遗菠，開(kāi)發(fā)和運(yùn)維職能的緊密協(xié)作是DevOps運(yùn)動(dòng)的最核心思想。要達(dá)到該目標(biāo)华蜒，企業(yè)如何為開(kāi)發(fā)和運(yùn)維建立一致的目標(biāo)辙纬，通過(guò)協(xié)作而非制衡的方式來(lái)共同面對(duì)同時(shí)提升吞吐量和保障穩(wěn)定性的挑戰(zhàn)是企業(yè)實(shí)施DevOps最重要的命題！組織需要下面這樣一種治理結(jié)構(gòu)：
圍繞著提供給用戶的產(chǎn)品和服務(wù)叭喜，建立包括產(chǎn)品設(shè)計(jì)贺拣、開(kāi)發(fā)、測(cè)試和運(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)營(yíng)分析的平臺(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)變從一開(kāi)始，很難在組織大范圍開(kāi)展盈厘，建議的是先建立特區(qū)睁枕，再逐步試點(diǎn)擴(kuò)大，最后實(shí)現(xiàn)突破；在轉(zhuǎn)變的過(guò)程中必然會(huì)涉及到部門職責(zé)范圍外遇、績(jī)效考評(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)咨詢過(guò)的一個(gè)客戶探討到如何進(jìn)行DevOps轉(zhuǎn)型時(shí)玩徊，開(kāi)發(fā)和運(yùn)維部門坐在一起探討。大家就運(yùn)維流程如何改變谨究、自動(dòng)化能力如何建設(shè)等都沒(méi)有異議恩袱，然而自始至終無(wú)法突破的終極問(wèn)題就是：無(wú)論我們?nèi)绾胃淖儯绻f(wàn)一生產(chǎn)環(huán)境出了問(wèn)題胶哲，誰(shuí)承擔(dān)責(zé)任畔塔？因?yàn)镈evOps能力的建設(shè)需要一個(gè)過(guò)程，開(kāi)發(fā)團(tuán)隊(duì)不敢承諾完全承擔(dān)責(zé)任鸯屿；而運(yùn)維因?yàn)槿趸瘜徟涂刂屏Τ憾郑舱J(rèn)為不該為其承擔(dān)責(zé)任。最終不了了之寄摆。
我認(rèn)為谅辣，根本的問(wèn)題出在文化，舊有的組織治理模式產(chǎn)生了各掃門前雪的官僚文化婶恼，沒(méi)有責(zé)任共擔(dān)桑阶，以及出現(xiàn)問(wèn)題必然問(wèn)責(zé)的文化。這種文化可能源自慣性的職能化思維勾邦，可能源自組織的績(jī)效考評(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)問(wèn)題，這必然是由于系統(tǒng)各個(gè)部分相互作用（從想法提出到軟件投產(chǎn)各個(gè)環(huán)節(jié)的相互作用昧港、系統(tǒng)與其它系統(tǒng)間的相互作用）產(chǎn)生的結(jié)果厦幅，對(duì)其中任何局部進(jìn)行懲罰無(wú)非是尋找替罪羊，有害而無(wú)益慨飘。這時(shí)候組織真正應(yīng)該做的，是相信每一個(gè)人都已經(jīng)做出了最大努力，將相關(guān)干系人拉到一起對(duì)問(wèn)題的根因進(jìn)行分析瓤的，找到能夠有效避免類似問(wè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)閉稽坤，以此來(lái)測(cè)試生產(chǎn)環(huán)境的快速恢復(fù)能力丈甸，促使各團(tuán)隊(duì)提升系統(tǒng)的穩(wěn)定性。我曾經(jīng)和國(guó)內(nèi)企業(yè)的開(kāi)發(fā)尿褪、運(yùn)維部門討論過(guò)這個(gè)實(shí)踐睦擂，有趣的是無(wú)論開(kāi)發(fā)還是運(yùn)維都跳出來(lái)反對(duì)該實(shí)踐，認(rèn)為無(wú)法落地杖玲。如果沒(méi)有這只“猴子”顿仇，大家可以給領(lǐng)導(dǎo)講自己的系統(tǒng)很穩(wěn)定（只要沒(méi)出問(wèn)題）；然而這只“猴子”可能會(huì)隨時(shí)暴露出自己的系統(tǒng)并不像自己所宣稱的那樣穩(wěn)定摆马，會(huì)降低自己在上級(jí)心目中的“有能力”印象臼闻，隨之而來(lái)的可能就是問(wèn)責(zé)、懲罰囤采。這樣的文化下述呐，大家真正關(guān)心的是如何給領(lǐng)導(dǎo)“表現(xiàn)”，而不是在真正的系統(tǒng)穩(wěn)定性上追求卓越蕉毯。
真正能夠?qū)崿F(xiàn)DevOps的組織乓搬，我們認(rèn)為需要具備下面這樣一些文化：
總結(jié)
無(wú)論是組織治理結(jié)構(gòu)、管理流程恕刘、工程技術(shù)能力還是文化特征缤谎，DevOps運(yùn)動(dòng)都和精益產(chǎn)品開(kāi)發(fā)、敏捷宣言所倡導(dǎo)的理念一致褐着。我認(rèn)為一個(gè)組織如果沒(méi)有充分經(jīng)歷過(guò)敏捷文化的熏陶坷澡，也很難實(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)新和快速市場(chǎng)響應(yīng)斟赚、為提升組織適應(yīng)力所進(jìn)行的精益敏捷組織轉(zhuǎn)型的一部分，這是一項(xiàng)系統(tǒng)工程差油。
盡管挑戰(zhàn)重重拗军，只要管理者首先從自身的管理思想出發(fā)做出改變任洞，從組織小范圍開(kāi)始，將各種職能的人員聚攏到一起发侵，設(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)生積極影響力愉烙，帶來(lái)組織效能的巨大提升讨盒。
