雷濤，DevOps 標(biāo)準(zhǔn)核心編寫(xiě)專家、Jenkins 全球大使，前百度 DevOps 產(chǎn)品架構(gòu)師，無(wú)人車工程教練。

先后就職于新浪網(wǎng)，摩托羅拉，諾基亞，愛(ài)立信，樂(lè)視等國(guó)內(nèi)外知名企業(yè)。

今天我要給大家講的主題是“成功實(shí)踐DevOps的五個(gè)關(guān)鍵因素。

主要分為四部分內(nèi)容，第一是VUCA時(shí)代如何應(yīng)對(duì)灰犀牛，第二是成功實(shí)現(xiàn)DevOps的五個(gè)關(guān)鍵因素，第三是企業(yè)如何開(kāi)始實(shí)施DevOps，相信這個(gè)會(huì)給各個(gè)企業(yè)帶來(lái)參考意見(jiàn)，最后是給大家回顧。

一、VUCA 時(shí)代如何應(yīng)對(duì)灰犀牛

首先，我們引入VUCA這個(gè)概念，VUCA是指組織處于一種易變性、不確定性、復(fù)雜性、模糊性狀態(tài)之中。

這個(gè)概念最早是美軍在20世紀(jì)90年代提出來(lái)的，引用描述冷戰(zhàn)結(jié)束之后的越來(lái)越不穩(wěn)定、不確定的、模棱兩可的、復(fù)雜多邊世界的關(guān)系，在2001年911的恐怖事件之后這個(gè)概念被確定，VUCA被戰(zhàn)略性和商業(yè)領(lǐng)袖來(lái)描述成為這種新常態(tài)的混亂和快速變化的商業(yè)環(huán)境。

為什么現(xiàn)在要提到VUCA這個(gè)詞？舉一些案例，明天顛覆你的對(duì)手并不在今天的視野之中，這個(gè)怎么理解？全球市場(chǎng)需求的高速變化，企業(yè)如果無(wú)法升級(jí)，就會(huì)面臨衰退或者滅亡，就像蘋(píng)果手機(jī)取代諾基亞，滴滴快車取代出租車，微信和釘釘取代短信，外賣取代方便面等等，就是說(shuō)顛覆我們的對(duì)手通常不是我們能看見(jiàn)的，這是在大行業(yè)跨領(lǐng)域的行業(yè)。

另外一個(gè)原因是現(xiàn)在不能騎自行車追汽車和火箭。麻省理工學(xué)院的研究員曾經(jīng)發(fā)表過(guò)一篇文章，一個(gè)AI改變2020年的效率法則。文章里提到，在全球這種發(fā)達(dá)的經(jīng)濟(jì)體當(dāng)中，前沿公司和落伍公司之間的差距在持續(xù)性的增大。比如在財(cái)富獨(dú)角獸榜單中的這些企業(yè)基本上都是指數(shù)型增長(zhǎng)的組織，像小米、滴滴、今日頭條、螞蟻，都是超過(guò)行業(yè)平均水平十倍以上的速度在增長(zhǎng)。

還有一個(gè)原因是科技現(xiàn)在越來(lái)越重要，大家都在說(shuō)科技以無(wú)形的資產(chǎn)超越有形的資產(chǎn)。像微軟市值，據(jù)說(shuō)1%都是實(shí)體資產(chǎn)，99%是公司代碼。所以說(shuō)在新型科技上投入越來(lái)越多，便會(huì)保持領(lǐng)先優(yōu)勢(shì)。

但是這里要提出一點(diǎn)，高科技企業(yè)和實(shí)體產(chǎn)業(yè)中的企業(yè)正好相反，對(duì)科技的投資是比較謹(jǐn)慎的態(tài)度。謹(jǐn)慎態(tài)度表現(xiàn)為否認(rèn)事實(shí)避重就輕，得過(guò)且過(guò)盲目樂(lè)觀，聽(tīng)信一些診斷延誤，推卸責(zé)任，同時(shí)也缺乏相關(guān)的經(jīng)驗(yàn)，也擔(dān)心引起一些消極的逃避。

客觀原因就是非高科技企業(yè)尤其是實(shí)體產(chǎn)業(yè)的試錯(cuò)成本通常高于互聯(lián)網(wǎng)行業(yè)，也有主觀因素，擔(dān)心看不懂，學(xué)不好學(xué)不會(huì)。

灰犀牛通常在工程學(xué)上有一個(gè)定義：在一次重大事故發(fā)生之前，已經(jīng)有超過(guò)99次小事故發(fā)生，但通常是人們忽視小事故的信號(hào)和警示，等到真正災(zāi)難發(fā)生時(shí)就比較晚了。

人們習(xí)以為常不加防范的小風(fēng)險(xiǎn)引起的大事故，就是常常說(shuō)的“灰犀牛”的事件，就是指概率極大、沖擊率特別強(qiáng)的風(fēng)險(xiǎn)。

[[322822]]

灰犀牛的事件無(wú)論在工作還是在生活中都是特別常見(jiàn)，比如項(xiàng)目中的灰犀牛，沒(méi)有簽合同就開(kāi)工；還有一些環(huán)境上的，無(wú)論是發(fā)達(dá)國(guó)家還是發(fā)展中國(guó)家，GDP的高速增長(zhǎng)通常以犧牲環(huán)境為代價(jià)；還有最新的例子，新冠疫情對(duì)美國(guó)來(lái)說(shuō)也是灰犀牛事件，就是無(wú)作為的美國(guó)政府任由風(fēng)險(xiǎn)的厚積薄發(fā)，釀成大禍。所以就是說(shuō)應(yīng)了那句話，出來(lái)混終究是要還的。

從客觀來(lái)說(shuō)體制機(jī)制的這種慣性、管理結(jié)構(gòu)的盲點(diǎn)、結(jié)構(gòu)程序的無(wú)效或者低效，還有技術(shù)平臺(tái)相對(duì)的成就也會(huì)拖延人們行動(dòng)的腳步，從而耽誤我們的處理和控制風(fēng)險(xiǎn)的最佳時(shí)機(jī)，我們應(yīng)該如何去應(yīng)對(duì)這些？首先我們要承認(rèn)危機(jī)的存在，要承認(rèn)灰犀牛危機(jī)事件的存在，不僅能幫助我們做機(jī)會(huì)，也能幫助我們把危機(jī)事件轉(zhuǎn)換成機(jī)遇。

第二，我們要確定灰犀牛事件的性質(zhì)。

第三，是不要靜止不動(dòng)。

第四，不要浪費(fèi)機(jī)會(huì)，要想辦法把危機(jī)轉(zhuǎn)換成機(jī)遇。

第五，站在順風(fēng)處，最好的領(lǐng)導(dǎo)是在危險(xiǎn)還沒(méi)有靠近的時(shí)候采取行動(dòng)。

我們發(fā)現(xiàn)灰犀牛事件的人，我們要成為控制灰犀牛事件的人，帶領(lǐng)大家躲避相關(guān)的風(fēng)險(xiǎn)。

基于以上體制的慣性、管理機(jī)構(gòu)的盲點(diǎn)、決策程序的低效，這些問(wèn)題恰好就是我們當(dāng)前很多公司在實(shí)施 DevOps 過(guò)程中面臨阻礙我們前進(jìn)的、急需解決的問(wèn)題。

因此這里回歸到的正題，給大家分享我們?cè)诟鞔笃髽I(yè)中調(diào)查研究后總結(jié)出來(lái)的關(guān)鍵因素，這五個(gè)因素分別是目標(biāo)、人員和文化、流程、平臺(tái)還有技術(shù)。

二、成功實(shí)踐 DevOps 的 5 個(gè)關(guān)鍵因素

1. 目標(biāo)對(duì)齊

第一個(gè)關(guān)鍵因素是業(yè)務(wù)目標(biāo)要對(duì)齊。IT的部門通常做了很多事情，為什么業(yè)務(wù)部門依然不高興？通過(guò)了解，業(yè)務(wù)部門認(rèn)為有四個(gè)方向。

第一是IT和業(yè)務(wù)面積無(wú)法適配的問(wèn)題，就是說(shuō)我們依然有一些科技官僚主義的存在，企業(yè)架構(gòu)師和技術(shù)管理者把大部分精力放在技術(shù)層面，與業(yè)務(wù)部門的溝通不是很順暢，缺乏一些系統(tǒng)化的運(yùn)營(yíng)管理思維，因此導(dǎo)致業(yè)務(wù)部門認(rèn)為我們雙方的愿景無(wú)法適配。

第二是IT部門聚焦在過(guò)程而不是結(jié)果。

第三，IT總是在解決自己的問(wèn)題，永遠(yuǎn)看不到一些產(chǎn)出，同時(shí)有新的問(wèn)題出現(xiàn)，我們就會(huì)針對(duì)性的補(bǔ)充相應(yīng)的，比如說(shuō)ID產(chǎn)品和服務(wù)還有采購(gòu)，久而久之造成內(nèi)部的問(wèn)題會(huì)越來(lái)越多，因?yàn)槲覀兓灸骋恍c(diǎn)，沒(méi)有從整個(gè)面。

第四，對(duì)于業(yè)務(wù)來(lái)說(shuō)，IT內(nèi)部就是像個(gè)黑盒子。因?yàn)楣芾聿块T通常說(shuō)IT是無(wú)法控制的黑盒，就是專注于技術(shù)，缺乏溝通，同時(shí)IT人員越來(lái)越貴，設(shè)備、服務(wù)、產(chǎn)品非常貴，同時(shí)IT功能不是很透明，而且跟業(yè)務(wù)的協(xié)作和通信比較差。所以業(yè)務(wù)部門認(rèn)為通常反饋的幾個(gè)問(wèn)題。

為什么IT部門做了這么多事，業(yè)務(wù)部門還不滿意？其實(shí)IT部門也有不爽，因?yàn)闃I(yè)務(wù)部門總是在辦公室想一些需求，或者提出的需求不夠清醒，剛剛開(kāi)始開(kāi)發(fā)就要改，甚至說(shuō)開(kāi)發(fā)完成上線最后還要改。另外一個(gè)經(jīng)常碰到，業(yè)務(wù)提出最高優(yōu)先級(jí)，沒(méi)有最低優(yōu)先級(jí)，不知道哪個(gè)到底是最高優(yōu)先級(jí)；永遠(yuǎn)不知道業(yè)務(wù)的指標(biāo)和收益，就是我們開(kāi)發(fā)出來(lái)的功能有沒(méi)有效果，完全是不知道的狀態(tài)。

所以目標(biāo)對(duì)齊，IT部門和業(yè)務(wù)部門之間一定要做充分的聯(lián)合，聚焦客戶價(jià)值；對(duì)業(yè)務(wù)的要求聚焦在客戶價(jià)值里面，客戶滿意度，關(guān)注于業(yè)務(wù)指標(biāo)，研發(fā)不能僅僅聚焦在按時(shí)交付，業(yè)務(wù)也不能僅僅聚焦在上線，要關(guān)注用戶的實(shí)際需求。

分享一個(gè)實(shí)際案例，昨天是收到一個(gè)大型企業(yè) DevOps 通信小組的反饋，他們很高興告訴我業(yè)務(wù)也加入他們的站會(huì)了，現(xiàn)在氛圍特別好，做到了真正的敏捷，他還特意強(qiáng)調(diào)一下真敏捷，什么意思？就是兩周一迭代，兩周一個(gè)投產(chǎn)，整個(gè)團(tuán)隊(duì)現(xiàn)在非常有成就感。

我們也了解了一下原因，首先是雙方部門領(lǐng)導(dǎo)的重視，給了大量的支持，還有前期一起進(jìn)行了相關(guān)的敏捷實(shí)踐，業(yè)務(wù)部門一起完成了相關(guān)的標(biāo)準(zhǔn)事件，同時(shí)請(qǐng)有經(jīng)驗(yàn)的人員給業(yè)務(wù)團(tuán)隊(duì)做相關(guān)的指引和培訓(xùn)，也請(qǐng)了外部的教練來(lái)做指導(dǎo)。

因此業(yè)務(wù)已經(jīng)逐漸接受了這種思維，通過(guò)這個(gè)案例再次印證了聚焦業(yè)務(wù)價(jià)值的快速交付，減少了業(yè)務(wù)概念從交付到反饋的流程，就是一定要關(guān)注全鏈路的協(xié)同工作，不斷改進(jìn)，有時(shí)間不斷做創(chuàng)新的事情。

2. 人員和文化

接下來(lái)是給大家介紹第二個(gè)關(guān)鍵要素，是人員和文化。這一方面?zhèn)鹘y(tǒng)的開(kāi)發(fā)模式有以下的顯著特點(diǎn)，一般是項(xiàng)目制，同時(shí)把項(xiàng)目分割成各個(gè)開(kāi)發(fā)階段，比如說(shuō)需求、定義、設(shè)計(jì)、編碼、單測(cè)等等，同時(shí)使用里程碑的方式，嚴(yán)格定義了開(kāi)發(fā)階段的輸出，如果一旦達(dá)不到相應(yīng)的輸出下一個(gè)階段不能展開(kāi)。

這個(gè)工作模式就是把開(kāi)發(fā)階段定義為黑盒，希望每個(gè)階段的人員只關(guān)心自己階段的工作，責(zé)任非常分散，各自負(fù)責(zé)各自的一部分。

好處在于可以讓各種角色的相關(guān)人員可以專注于本職工作，提高階段的效率。但是壞處也非常明顯，主要表現(xiàn)在出了問(wèn)題大家就會(huì)相互推諉責(zé)任。另外在每一個(gè)開(kāi)發(fā)階段，都會(huì)有一些信息，可能其他階段的人員沒(méi)有辦法了解到，所以就會(huì)造成大面積相互理解的偏差等。

其實(shí)這正好是 DevOps 嘗試要去解決的問(wèn)題，即如何讓企業(yè)內(nèi)部的開(kāi)發(fā)運(yùn)維和其他組織高效協(xié)作，達(dá)到一系列共同的目標(biāo)，更快、更可靠向客戶還有終端用戶去提交軟件和相應(yīng)的服務(wù)。

所以通常會(huì)演變?yōu)閮蓚€(gè)團(tuán)隊(duì)，以前項(xiàng)目制的團(tuán)隊(duì)通常演變?yōu)槎喙δ艿漠a(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)，就像屏幕右下角所示，大家聚集在一起，團(tuán)隊(duì)里面有開(kāi)發(fā)、測(cè)試、運(yùn)維，甚至還有我們的業(yè)務(wù)人員，在互聯(lián)網(wǎng)公司也是叫產(chǎn)品經(jīng)理，大家一起共同為整個(gè)產(chǎn)品和服務(wù)的承辦去承擔(dān)相應(yīng)的責(zé)任，因此大家的積極性相對(duì)比較高，這是一塊。

另外之后大家會(huì)組成一個(gè)新的 DevOps 平臺(tái)的團(tuán)隊(duì)，為什么組建這樣的平臺(tái)團(tuán)隊(duì)？我們對(duì)于多功能開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)是負(fù)責(zé)某一個(gè)產(chǎn)品或者服務(wù)的開(kāi)發(fā)，甚至服務(wù)的交付，你不可能在這個(gè)團(tuán)隊(duì)里面要做 CI/CD，自己安裝配置，甚至是維護(hù)這些相應(yīng)的工具平臺(tái)，因此會(huì)得不償失。

在這樣的背景之下會(huì)成立一個(gè)新的DevOps平臺(tái)團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)一般會(huì)負(fù)責(zé)公司相關(guān)產(chǎn)品的整個(gè)端到端的工具鏈的貫穿，還有流程和工具的結(jié)合相關(guān)的工作。

因此類似于右下角的圖，他們給相關(guān)的產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)提供一些工具或者平臺(tái)甚至是自助式的服務(wù)，讓這些開(kāi)發(fā)團(tuán)隊(duì)很容易去介入到，因此這是一個(gè)非常巨大的轉(zhuǎn)變，尤其是對(duì)于很多傳統(tǒng)的企業(yè)，他們還沒(méi)有開(kāi)始做敏捷和DevOps實(shí)踐之前，是很難想象的一個(gè)事。同時(shí)無(wú)論對(duì)于多功能產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)，一般的建議人員是在九人左右，也有個(gè)別組織在15人左右，但不超過(guò)15人。

另外相信有很多人看到有一些學(xué)習(xí)型的組織，這樣的組織一般會(huì)建議說(shuō)大家通過(guò)相應(yīng)的組織結(jié)構(gòu)的轉(zhuǎn)變，人員團(tuán)隊(duì)之間相互學(xué)習(xí)，通過(guò)重組的方式充分釋放團(tuán)隊(duì)和人員的力量。

之前的模式主要是分層特別明顯的組織架構(gòu)，從控制型轉(zhuǎn)變?yōu)樘摂M化或者網(wǎng)絡(luò)狀的組織，達(dá)到相關(guān)的事情對(duì)齊，還有足夠的授權(quán)方式，因此之前可能是謙虛合作的模式，后續(xù)可能是大家形成一個(gè)高度合作的小組去承擔(dān)整個(gè)產(chǎn)品的承辦。

剛才講了一些理論，現(xiàn)在是給大家具體的案例，這個(gè)案例有一個(gè)大的背景，就是說(shuō)某個(gè)企業(yè)他已經(jīng)對(duì) DevOps 相關(guān)實(shí)踐探索了一段時(shí)間，可能一到兩年，根據(jù)網(wǎng)上的建議也組建了產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)和 DevOps 平臺(tái)的小組，也開(kāi)發(fā)了 DevOps 流水線平臺(tái)，但產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)和 DevOps 平臺(tái)小組之間依然沒(méi)有辦法很好地去合作得順暢。

常見(jiàn)的問(wèn)題比如說(shuō)平臺(tái)貌似有一些自動(dòng)化的功能，但是用起來(lái)很別扭，要用平臺(tái)要先申請(qǐng)資源自己再配置進(jìn)去，很麻煩，或者要上線投產(chǎn)的時(shí)候需要大量的溝通，或多或少每次上線都會(huì)遇到一些問(wèn)題，這是大概的背景。

經(jīng)過(guò)和相關(guān)的管理者做商量和討論，我們就用學(xué)習(xí)型組織的建議，比如說(shuō)建立共同的愿景，團(tuán)隊(duì)一起學(xué)習(xí)，同時(shí)逐漸改變團(tuán)隊(duì)的模式，最后從系統(tǒng)化思考怎么樣優(yōu)化這些事。最后我們想到一個(gè)辦法，就是說(shuō)設(shè)置一個(gè)輪崗，輪崗的目標(biāo)就是增進(jìn)團(tuán)隊(duì)的協(xié)作，最終達(dá)到上線。

這里說(shuō)到非常關(guān)鍵的點(diǎn)，首先設(shè)置短期的輪崗機(jī)制。一開(kāi)始是志愿者的模式，大家自愿報(bào)名，為期兩個(gè)月，其中第一周是相關(guān)的學(xué)習(xí)，比如說(shuō)開(kāi)發(fā)人員會(huì)學(xué)習(xí)怎么樣對(duì)產(chǎn)品和服務(wù)做部署上線，那么第一周去學(xué)習(xí)，后面的八周輪崗，我們有需要做上線的時(shí)候由開(kāi)發(fā)同學(xué)做相應(yīng)的操作，因此整個(gè)達(dá)到開(kāi)發(fā)測(cè)試運(yùn)維責(zé)任共享的情況。同時(shí)對(duì)于運(yùn)維同學(xué)來(lái)說(shuō)也會(huì)更好了解產(chǎn)品、系統(tǒng)和流程，因此會(huì)讓運(yùn)維同學(xué)做相應(yīng)的測(cè)試類型的工作，這樣比較好了解我們的業(yè)務(wù)模式。

另外就是要?jiǎng)?chuàng)建一個(gè)好的環(huán)境，大家在良好的氛圍里面相互學(xué)習(xí)，同時(shí)最后是慶祝每一次的成功，也慶祝每一次的失敗，對(duì)于成功比較常見(jiàn)，對(duì)于失敗也會(huì)采取一些措施，比如說(shuō)會(huì)讓有問(wèn)題的相關(guān)人員，買一些吃的請(qǐng)大家，通常來(lái)說(shuō)吃人嘴短，你吃了人家的東西后續(xù)遇到問(wèn)題的時(shí)候不會(huì)逃避，而是真誠(chéng)幫助大家把事情做好，因此這是輪崗的案例，里面融合了大量文化的一些理論在里邊，最后取得了一個(gè)比較好的效果。

3. 流程

接下來(lái)我們看第三個(gè)要素，就是流程。我們先看一下四個(gè)趨勢(shì)圖，非常直觀展現(xiàn)了敏捷開(kāi)發(fā)模式和傳統(tǒng)開(kāi)發(fā)模式的不同，虛線表示傳統(tǒng)的，實(shí)線是敏捷的開(kāi)發(fā)模式。

對(duì)于項(xiàng)目能見(jiàn)度來(lái)說(shuō)，在項(xiàng)目立項(xiàng)之初，大家對(duì)項(xiàng)目的關(guān)注度和期望很高，因此一開(kāi)始是比較高的能見(jiàn)度，但是在執(zhí)行的過(guò)程中非常明顯。對(duì)于傳統(tǒng)的開(kāi)發(fā)模式，它的能見(jiàn)度會(huì)越來(lái)越低，直到一兩年之后說(shuō)能發(fā)布了，就是廣告的宣傳，這時(shí)候大家很激動(dòng)，說(shuō)上一任老板在的時(shí)候采購(gòu)的工具終于要交付了，會(huì)有這些感覺(jué)。

那么在敏捷項(xiàng)目實(shí)踐中會(huì)采用一些迭代開(kāi)發(fā)的方式，一開(kāi)始我們相關(guān)的項(xiàng)目的能見(jiàn)度就比較高，一直會(huì)跟客戶層面做協(xié)助，去探討相關(guān)的需求還有實(shí)現(xiàn)不斷做反饋和改進(jìn)，最后我們的業(yè)務(wù)價(jià)值也是持續(xù)穩(wěn)步上升，同時(shí)風(fēng)險(xiǎn)也被很好的控制。

這里舉個(gè)在融資界的例子，就是傳統(tǒng)的融資界的融資周期基本每年一次，但是根據(jù)我們的截圖顯示的，他們?cè)诤茉缫郧?，?016年的時(shí)候開(kāi)始做敏捷化的融資，比如說(shuō)去通過(guò)一些周期性的融資，以前是一年一次，現(xiàn)在是按季度或者更短，做相關(guān)的投資，因此這種風(fēng)險(xiǎn)相對(duì)來(lái)說(shuō)比較可控。

那除了這些因素存在明顯的差別之外，其他還有項(xiàng)目的撥款周期、交付周期、反饋周期等等也存在著巨大的不同，在傳統(tǒng)的開(kāi)發(fā)模式下通常大批量一次性這種方式去交付，但是在新的 DevOps 的模式下，項(xiàng)目的撥款周期類似于融資界或者小批量迭代的交付，收益或者收視率比較好了，我們就繼續(xù)投，如果效果不好我們就暫停，可以及時(shí)做止損。

4. 平臺(tái)

接下來(lái)給大家分享一下，第四個(gè)關(guān)鍵要素—平臺(tái)，剛才王洋老師也介紹了DevOps平臺(tái)相關(guān)的事情，這里給大家一些建議，對(duì)于平臺(tái)這一塊有三個(gè)需要注意的方向，分別是自動(dòng)化、自主服務(wù)、可視化，自動(dòng)化一定要做標(biāo)準(zhǔn)化還有相應(yīng)的版本，另外對(duì)于平臺(tái)這一塊去實(shí)現(xiàn)自助服務(wù)，我們認(rèn)為也是很關(guān)鍵的，另外是可視化，端到端流水線的可視化，還有度量的可視化，業(yè)務(wù)數(shù)據(jù)、研發(fā)的效能、質(zhì)量、速度、滿意度等等，都可以通過(guò)可視化的方式去改進(jìn)出來(lái)。

這一頁(yè)給大家舉個(gè)例子，我一直在想一個(gè)例子，這是從網(wǎng)上找到的一系列的照片，這個(gè)例子就是在現(xiàn)實(shí)生活中或者項(xiàng)目中通常會(huì)遇到類似的問(wèn)題。比如牙膏快用完了，很多人說(shuō)扔了，再買一個(gè)。

但在疫情下，大家會(huì)覺(jué)得這些東西會(huì)變得越來(lái)越珍貴，因此會(huì)想盡一切辦法怎樣更高效運(yùn)用，那應(yīng)該怎么做？有些人就說(shuō)我特別擅長(zhǎng)做自動(dòng)化，就做了一個(gè)這樣的自動(dòng)化方式，特別獨(dú)特的一次性的自動(dòng)化，沒(méi)有辦法做重用，大家會(huì)覺(jué)得這個(gè)例子可能很可笑。

但是這個(gè)例子在企業(yè)里面或者項(xiàng)目里面是非常常見(jiàn)的，為什么大家回用這個(gè)耳機(jī)線綁牙膏？因?yàn)榭赡苓@個(gè)人手里只有這個(gè)東西，或者他的理解范圍內(nèi)認(rèn)為這個(gè)線是最好的工具，所以在他的知識(shí)范圍內(nèi)這是能想到的最好的辦法。

但也有一些人會(huì)去買非常高大上的工具，像自動(dòng)擠牙膏還有自動(dòng)感應(yīng)的工具，大家覺(jué)得非常好。也有這樣一種場(chǎng)景，尤其對(duì)于大型的企業(yè)，存在一定的年頭之后會(huì)有大量的不同的業(yè)務(wù)模式，類似于家里有晚年、中年、青年、少年、嬰兒，那在這樣的復(fù)雜環(huán)境下買這樣的工具是否能很好的解決問(wèn)題，這是大家需要關(guān)心的。

還是以擠牙膏為例，可能小孩用牙膏的量特別少，對(duì)于年輕人來(lái)說(shuō)一次性要擠滿整個(gè)牙刷才行。

那用標(biāo)準(zhǔn)化的工具怎樣滿足不同的用戶的需求？所以大家會(huì)說(shuō)通常有一些公司開(kāi)發(fā)得特別好，是否能解決我們的問(wèn)題？所以這是大家需要提前考慮的點(diǎn)，如果通過(guò)一些調(diào)研發(fā)現(xiàn)工具比較適合，滿足目前的情況，在資金允許的范圍下鼓勵(lì)大家買這些工具。

對(duì)于這個(gè)例子也是一樣，我們要考慮牙膏的形狀，后續(xù)的清潔維護(hù)，還有電源等等的情況也要做相應(yīng)的考慮。

其實(shí)對(duì)于這樣的例子在工作和生活中非常常見(jiàn)，一般是給到的建議是一定要與領(lǐng)域相對(duì)比較專業(yè)的人做溝通和交流，因?yàn)樗麑?duì)這個(gè)領(lǐng)域的關(guān)注點(diǎn)可能超越公司內(nèi)部的開(kāi)發(fā)、測(cè)試、運(yùn)維人員，也許可以通過(guò)小工具可以解決這樣的問(wèn)題，同時(shí)又非常經(jīng)濟(jì)。所以回過(guò)頭來(lái)看看各個(gè)企業(yè)的內(nèi)部，首先建議大家做改進(jìn)的流程，對(duì)現(xiàn)有的流程做梳理，再看如何在現(xiàn)有的流程做刪改和相關(guān)的優(yōu)化。

第二是促進(jìn)內(nèi)部和外部的開(kāi)源之間的概念，還有相關(guān)的合作和協(xié)作，公司越來(lái)越大，或多或少存在重復(fù)的事，所以要不斷重復(fù)開(kāi)源的機(jī)制。還有一個(gè)是要快速失敗，對(duì)于失敗來(lái)說(shuō)我們要快速試錯(cuò)。

最后還有一個(gè)關(guān)于自動(dòng)化，它的三個(gè)前提條件非常關(guān)鍵，第一是標(biāo)準(zhǔn)化，一定要做標(biāo)準(zhǔn)，要在相應(yīng)的流程和規(guī)范的梳理，只有形成流程和規(guī)范的標(biāo)準(zhǔn)，才能用腳本實(shí)現(xiàn)，這樣實(shí)現(xiàn)之后才有自動(dòng)化，那后續(xù)相關(guān)的維護(hù)和功能的拓展才有相關(guān)的版本化的管理方式。

第二個(gè)方面，對(duì)于平臺(tái)化建設(shè)的自助服務(wù)，這一塊最關(guān)鍵的是一定要去給大家打造一個(gè)盡量的傻瓜式的自助服務(wù)平臺(tái)，相關(guān)的好處和優(yōu)點(diǎn)都有列舉出來(lái)，首先解決大家把流程融入工具平臺(tái)的最佳做法，我們定義了一些流程規(guī)范，公司說(shuō)有自己的流程規(guī)范但是沒(méi)有辦法落地，做法很不一樣，這其實(shí)是很多公司常見(jiàn)的問(wèn)題，我們推薦的做法就是找到特殊的突破口，同時(shí)結(jié)合現(xiàn)有的工具，把流程融入到工具，同時(shí)也有統(tǒng)一的配置可以統(tǒng)一管理，還有自助服務(wù)可以帶來(lái)更高程度的敏捷性等等，這樣同時(shí)有利于我們最佳實(shí)踐的推廣，同時(shí)減少風(fēng)險(xiǎn)，也有利于安全和審計(jì)。

比如說(shuō)組織級(jí)這邊可以定義最基礎(chǔ)的規(guī)范，比如說(shuō)安全的規(guī)范，質(zhì)量的門禁式規(guī)范，對(duì)于基礎(chǔ)的規(guī)范我們可以把它植入我們的自助平臺(tái)里面去，不管什么業(yè)務(wù)，如果符合相應(yīng)的要求就會(huì)給你自動(dòng)的開(kāi)通相應(yīng)的任務(wù)，或者對(duì)對(duì)應(yīng)的任務(wù)做強(qiáng)制執(zhí)行，這樣就比較有利于相關(guān)的風(fēng)險(xiǎn)控制，同時(shí)后續(xù)對(duì)于自動(dòng)化的平臺(tái)會(huì)不斷做相應(yīng)的審計(jì)的工作，這樣會(huì)更好的督促大家使用的規(guī)范化，有利于平臺(tái)更多功能的開(kāi)發(fā)。

第三個(gè)方面就是關(guān)于平臺(tái)是度量可視化，這個(gè)非常關(guān)鍵，前面還有一個(gè)流水線的可視化不做重點(diǎn)講解，今天重點(diǎn)講度量可視化，通常來(lái)說(shuō)分為四大塊，第一是合規(guī)的展示，安全的合規(guī)、開(kāi)源的合規(guī)尤其是軟件產(chǎn)品服務(wù)要出口，出口到歐美的時(shí)候大家一定要關(guān)注開(kāi)源的合規(guī)，否則會(huì)被重罰。另外還有可靠性展示，偏運(yùn)維，就是我們服務(wù)的時(shí)長(zhǎng)，監(jiān)控預(yù)警。

今天重點(diǎn)說(shuō)的是左邊這兩個(gè)指標(biāo)，第一是CI/CD指標(biāo)，就是開(kāi)發(fā)過(guò)程中相關(guān)的比較關(guān)鍵的指標(biāo)，用得比較多也比較有效果的就是交互時(shí)長(zhǎng)，就是出了問(wèn)題多長(zhǎng)時(shí)間可以修復(fù)，直接關(guān)系到整個(gè)團(tuán)隊(duì)的開(kāi)發(fā)文化還有規(guī)范的執(zhí)行還有DevOps的落地，都有直接間接的影響。

另外變更覆蓋率，測(cè)試覆蓋率，測(cè)試健康度的檢查，同時(shí)還有公司會(huì)做CI/CD的免測(cè)率，會(huì)根據(jù)免測(cè)率的情況給你的產(chǎn)品質(zhì)量打分，你產(chǎn)品質(zhì)量相關(guān)的分?jǐn)?shù)越高，免測(cè)率越高，類似于國(guó)家提出的質(zhì)量免檢的手段，這樣會(huì)更加有利于產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)去不斷提升他們內(nèi)部的質(zhì)量，同時(shí)要不斷解決我們的技術(shù)棧，關(guān)注于質(zhì)量或者開(kāi)發(fā)提交的打回率，做到有問(wèn)題及時(shí)發(fā)現(xiàn)。

還有大家現(xiàn)在越來(lái)越關(guān)注業(yè)務(wù)價(jià)值指標(biāo)，通常體現(xiàn)在業(yè)務(wù)的流動(dòng)速度、流動(dòng)時(shí)長(zhǎng)，其他的比如說(shuō)交付周期，現(xiàn)在還有一些公司也會(huì)關(guān)注創(chuàng)新的時(shí)長(zhǎng)，說(shuō)最寶貴的研發(fā)測(cè)試人員他們最主要的工作到底是在做創(chuàng)新類的事，還是解BUG，還是開(kāi)會(huì)？所以這一塊是大家越來(lái)越關(guān)注的指標(biāo)。

接下來(lái)是給大家分享一下我們?cè)诟鞔蠊咀咴L之后梳理出來(lái)的DevOps的度量模型，這一塊也是目前很多公司都在準(zhǔn)備做的事情，給大家做一個(gè)初步的分享。

首先度量體系的目標(biāo)我們是要打造一個(gè)相關(guān)的度量平臺(tái)，同時(shí)對(duì)生產(chǎn)率、交付質(zhì)量、速度、滿意度提出一個(gè)可視化的展示，所以度量指標(biāo)的意義就是能幫助我們?nèi)嬖u(píng)估我們 DevOps 相關(guān)實(shí)踐落地的情況，同時(shí)根據(jù)這樣的可視化的體系，能夠給我們合理指引我們哪里做得好，哪里做得不好，哪里還沒(méi)有開(kāi)始，同時(shí)達(dá)到一個(gè)快速達(dá)成，不斷做持續(xù)相關(guān)優(yōu)化改進(jìn)的事。

另外對(duì)于度量體系建設(shè)，很多公司都覺(jué)得是特別困難的事，這也是一個(gè)現(xiàn)狀，就是分析建設(shè)難點(diǎn)主要表現(xiàn)為這幾個(gè)，第一是高復(fù)雜度，貫穿整個(gè)階段，產(chǎn)品的研發(fā)、測(cè)試等等，同時(shí)還會(huì)涉及到業(yè)務(wù)。

第二是度量體系沒(méi)有現(xiàn)成的工具，當(dāng)然市面也有一些工具，很多公司也花大價(jià)錢買了，但是拿回來(lái)用不了，沒(méi)有專業(yè)的人做相關(guān)的配置，造成了巨大的浪費(fèi)。

因此度量體系需要高度的定制化，同時(shí)需要比較好的應(yīng)急，首先你要能把所有的工具鏈貫穿才能收集到這樣的數(shù)據(jù)，如果連工具鏈還沒(méi)有貫穿，或者沒(méi)有引入相應(yīng)的數(shù)據(jù)，那這些數(shù)據(jù)從哪里獲取，因此是有一些基礎(chǔ)在里面，就像剛才說(shuō)的現(xiàn)在有各種各樣的工具，同時(shí)這些工具存在于各種部門團(tuán)隊(duì)里面，因此我們想去把數(shù)據(jù)收集過(guò)來(lái)存在相關(guān)的復(fù)雜度。

最后一個(gè)我們一定要有相關(guān)的理論模型支撐，這個(gè)模型是非常困難的事，那這里面給大家分享右邊這幾個(gè)我們作為 DevOps 度量模型的設(shè)想。

最上面這個(gè)度量體系分為三個(gè)維度，個(gè)人、團(tuán)隊(duì)和系統(tǒng)，對(duì)于個(gè)人來(lái)說(shuō)這一塊最常用的場(chǎng)景就是工程師畫(huà)像，大家用得比較多，這個(gè)通過(guò)個(gè)人的經(jīng)驗(yàn)、能力、專業(yè)知識(shí)、意愿和工作來(lái)做相應(yīng)的模型，再結(jié)合相關(guān)工程師的過(guò)去、現(xiàn)在、未來(lái)做相關(guān)的計(jì)算、學(xué)習(xí)，得出一些相應(yīng)的數(shù)據(jù)。團(tuán)隊(duì)這一塊是充分利用每個(gè)團(tuán)隊(duì)里面工程師人員，各種角色，同時(shí)對(duì)于團(tuán)隊(duì)所承接的業(yè)務(wù)或者產(chǎn)品的復(fù)雜度、收益做綜合的計(jì)算，畫(huà)出團(tuán)隊(duì)的畫(huà)像。

另外系統(tǒng)也是大家關(guān)注的，也有一個(gè)示意圖，是產(chǎn)生系統(tǒng)的畫(huà)像，這個(gè)畫(huà)像里面是展示了兩個(gè)系統(tǒng)的能力成熟度，A系統(tǒng)68分，B系統(tǒng)72分，就是每個(gè)方向的強(qiáng)弱是非常直觀的展示，如果我們想對(duì)哪一個(gè)系統(tǒng)想更進(jìn)一步的了解，都可以點(diǎn)進(jìn)去，對(duì)相關(guān)的進(jìn)行了解。

5. 技術(shù)

第五個(gè)關(guān)鍵要素就是技術(shù)，大家應(yīng)該非常關(guān)注，從開(kāi)發(fā)的模式的轉(zhuǎn)變、應(yīng)用架構(gòu)的轉(zhuǎn)變還有打包，還有托管機(jī)房的轉(zhuǎn)變，都逐漸轉(zhuǎn)換到 DevOps 微服務(wù)、容器和云化。

這里給大家提的一點(diǎn)，對(duì)于有不同的開(kāi)發(fā)模式，我們會(huì)有不同的部署頻率，因此左邊是列了一些相關(guān)的部署頻率。還有一點(diǎn)不見(jiàn)得一定要從單體轉(zhuǎn)換到微服務(wù)，這個(gè)一定要根據(jù)實(shí)際的業(yè)務(wù)情況做相應(yīng)的判斷和分析，那么如果你的業(yè)務(wù)情況就是非常穩(wěn)態(tài)，需求變化就是沒(méi)有那么快，同時(shí)需求也被很早確定下來(lái)，可能這種情況下沒(méi)有必要做強(qiáng)迫性微服務(wù)的轉(zhuǎn)換，這是給大家的一個(gè)建議，包括其他的開(kāi)發(fā)模式，虛機(jī)到容器到上云都是類似的。

最后關(guān)于技術(shù)這一點(diǎn)大家通常會(huì)忘記一個(gè)非常關(guān)鍵的點(diǎn)就是我們跑得太快沒(méi)有功夫或者沒(méi)有時(shí)間修我們的技術(shù)棧，這一點(diǎn)非常關(guān)鍵，導(dǎo)致你的系統(tǒng)跑到一定的程度會(huì)產(chǎn)生大量的問(wèn)題，所以在技術(shù)這一塊給大家重點(diǎn)強(qiáng)調(diào)，我們一定要定期修復(fù)技術(shù)棧。

三、企業(yè)如何開(kāi)始實(shí)施 DevOps

說(shuō)了這么多關(guān)鍵的要素，大家可能會(huì)比較關(guān)注的就是對(duì)于不同的企業(yè)，DevOps 落地應(yīng)該如何開(kāi)始？現(xiàn)在各種業(yè)務(wù)系統(tǒng)越來(lái)越復(fù)雜，甚至已經(jīng)不是一個(gè)產(chǎn)品或者一家公司的多個(gè)產(chǎn)品之間有關(guān)聯(lián)，已經(jīng)是整個(gè)生態(tài)之間的關(guān)聯(lián)關(guān)系，那這種怎么做？還有一個(gè)是各種傳統(tǒng)的企業(yè)在拼命招一些自有的科技人員，以前可能說(shuō)大家都是外采一些軟件和服務(wù)，現(xiàn)在都是從幾百人的規(guī)模逐漸發(fā)展到上千人自有的科技人才，人員增加之后對(duì)于我們內(nèi)部的IT的工具平臺(tái)系統(tǒng)帶來(lái)的業(yè)務(wù)的挑戰(zhàn)性，也是越來(lái)越嚴(yán)重。

對(duì)于工具系統(tǒng)這一塊，我們?nèi)藛T的擴(kuò)張之后勢(shì)必會(huì)產(chǎn)生大量的工具系統(tǒng)，是技術(shù)的不斷迭代，有一些團(tuán)隊(duì)可能會(huì)積極引入新技術(shù)，那復(fù)雜的系統(tǒng)我們應(yīng)該如何考慮，怎么推廣 DevOps，DevOps 對(duì)于復(fù)雜的場(chǎng)景是否還有效？我們是否應(yīng)該尋找一些幫助？比如說(shuō)對(duì)外去尋找一些咨詢的力量，對(duì)內(nèi)向其他做的好的部門取經(jīng)，因此我們強(qiáng)烈建議，通過(guò)這種方式，我們左手是用 DevOps 的標(biāo)準(zhǔn)，右手是 DevOps 平臺(tái)，通過(guò)兩手開(kāi)展 DevOps 相關(guān)實(shí)踐的落地。

這里快速介紹一下研發(fā)運(yùn)營(yíng)一體化（DevOps）能力成熟度模型，DevOps 標(biāo)準(zhǔn)2018年在聯(lián)合國(guó) ITU-T 立項(xiàng)。它分為幾大塊，第一主要是在敏捷開(kāi)發(fā)管理，對(duì)需求還有價(jià)值流相關(guān)的梳理；第二是持續(xù)交付，也是我們目前大家所熟知的標(biāo)準(zhǔn)三，包括了七個(gè)能力子域，14個(gè)能力項(xiàng)，49個(gè)能力子項(xiàng)，是覆蓋了整個(gè)持續(xù)交付端到端的過(guò)程，對(duì)大家在實(shí)施 DevOps 的過(guò)程之中非常有參考借鑒的意義。很多的研發(fā)或者測(cè)試人員來(lái)說(shuō)他的知識(shí)范圍受限，不可能考慮那么多，因此這是大家理論參考的依據(jù)。剩下的幾個(gè)標(biāo)準(zhǔn)是應(yīng)用架構(gòu)設(shè)計(jì)，安全和風(fēng)險(xiǎn)管理，同時(shí)還有系統(tǒng)和工具。

除了以 DevOps 能力成熟度模型為理論基礎(chǔ)，另外一件事就是公司內(nèi)部的 DevOps 平臺(tái)建設(shè)，通常來(lái)說(shuō)這個(gè)平臺(tái)建設(shè)分為三個(gè)階段，從無(wú)到有到引入工具。工具多了之后，應(yīng)該進(jìn)入哪一個(gè)工具，怎么辦？就做半自研，把以下相關(guān)的工具以連接的方式連接起來(lái)，或者頁(yè)面的方式切入進(jìn)來(lái)。

第三個(gè)就是無(wú)論是開(kāi)源還是商業(yè)可能沒(méi)有辦法支撐或者更好的支撐業(yè)務(wù)模式的時(shí)候我們一般會(huì)采取做自研，以及前面說(shuō)的從開(kāi)源那些大量的經(jīng)驗(yàn)我們可以從小到大逐漸把我們平臺(tái)建設(shè)起來(lái)。

四、回顧和展望

最后一塊回顧和展望，前面說(shuō)了成功實(shí)踐 DevOps 的因素有五個(gè)。

• 第一就是目標(biāo)對(duì)齊；
• 第二是人員和文化，非常關(guān)鍵，也是需要各位領(lǐng)導(dǎo)逐漸做的事情，通過(guò)潛移默化的方式讓大家去了解；
• 第三是流程做相應(yīng)的改造，平臺(tái)做相應(yīng)的建設(shè)；平臺(tái)里面又有三個(gè)方向：自動(dòng)化、流水線、度量，
• 第四是技術(shù)，這一塊非常關(guān)鍵。

對(duì)于后續(xù)的展望，目前業(yè)界也做了大量的討論，就是主要我們認(rèn)為幾個(gè)方向是在DevOps相關(guān)的展望是在以下幾個(gè)方面：

第一是項(xiàng)目到產(chǎn)品的研發(fā)模式。

第二是為 DevOps 平臺(tái)建設(shè)結(jié)實(shí)有效的防護(hù)欄，就是打造一個(gè) DevOps 平臺(tái)，這個(gè)平臺(tái)要有自服務(wù)的屬性，自助的屬性，讓大家自助，也就意味著要有相應(yīng)的防御的措施，不要隨便越界獲取相應(yīng)的權(quán)限；相應(yīng)的審批功能，這是很多公司做自助平臺(tái)的時(shí)候缺乏考慮的。

第三是新的部署模式，一般是開(kāi)發(fā)部門做，最后執(zhí)行上線的時(shí)候雖然是在某一個(gè) DevOps 平臺(tái)里面做上線，但是這個(gè)時(shí)候依然是由運(yùn)維人員做執(zhí)行上線，后續(xù)我們覺(jué)得會(huì)逐漸轉(zhuǎn)變?yōu)樽灾脚_(tái)建設(shè)越來(lái)越完善，因此提供足夠的監(jiān)控和相關(guān)的審計(jì)功能，這樣當(dāng)我們的項(xiàng)目制到產(chǎn)品制之后，產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)就完全可以做到自助式的變更流程，甚至說(shuō)代碼提交，通過(guò)各種自動(dòng)化的有效檢測(cè)手段自助上線了。

第四個(gè)也是非常關(guān)鍵要關(guān)注用戶體驗(yàn)，大家非常熟知的用戶體驗(yàn)一般說(shuō)是對(duì)外部用戶的體驗(yàn)，通常我們做 DevOps 平臺(tái)的時(shí)候通常忽略了內(nèi)部的用戶體驗(yàn)，比如說(shuō)有很多公司認(rèn)為我招一個(gè) JAVA 工程師就可以開(kāi)發(fā) DevOps 平臺(tái)，是可以，但是對(duì)于開(kāi)發(fā)測(cè)試運(yùn)維人員的體驗(yàn)都是非常糟糕的，所以我們一定要關(guān)注用戶的體驗(yàn)。

對(duì)于自動(dòng)化部署平臺(tái)我們要關(guān)注運(yùn)維相關(guān)的體驗(yàn)，對(duì)于 DevOps 平臺(tái)關(guān)注研發(fā)測(cè)試的體驗(yàn)，這是大家一定要關(guān)注的，否則很多公司開(kāi)發(fā)了 DevOps 平臺(tái)，最后推廣的時(shí)候遇到很多問(wèn)題，大家覺(jué)得不好用，因此處處碰壁，沒(méi)有辦法做下一步。

以上這幾個(gè)點(diǎn)是我認(rèn)為是在今年比較重點(diǎn)的發(fā)展方向，我的分享就到這里，謝謝大家。