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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[322822]]

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

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

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

第三，是不要靜止不動。

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

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

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

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

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

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

1. 目標(biāo)對齊

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

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

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

第三，IT總是在解決自己的問題，永遠(yuǎn)看不到一些產(chǎn)出，同時有新的問題出現(xiàn)，我們就會針對性的補(bǔ)充相應(yīng)的，比如說ID產(chǎn)品和服務(wù)還有采購，久而久之造成內(nèi)部的問題會越來越多，因為我們基本某一些點，沒有從整個面。

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

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

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

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

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

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

2. 人員和文化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 流程

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

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

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

這里舉個在融資界的例子，就是傳統(tǒng)的融資界的融資周期基本每年一次，但是根據(jù)我們的截圖顯示的，他們在很早以前，在2016年的時候開始做敏捷化的融資，比如說去通過一些周期性的融資，以前是一年一次，現(xiàn)在是按季度或者更短，做相關(guān)的投資，因此這種風(fēng)險相對來說比較可控。

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

4. 平臺

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

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

但在疫情下，大家會覺得這些東西會變得越來越珍貴，因此會想盡一切辦法怎樣更高效運用，那應(yīng)該怎么做？有些人就說我特別擅長做自動化，就做了一個這樣的自動化方式，特別獨特的一次性的自動化，沒有辦法做重用，大家會覺得這個例子可能很可笑。

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

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

還是以擠牙膏為例，可能小孩用牙膏的量特別少，對于年輕人來說一次性要擠滿整個牙刷才行。

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

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

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

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

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

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

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

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

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

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

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

接下來是給大家分享一下我們在各大公司走訪之后梳理出來的DevOps的度量模型，這一塊也是目前很多公司都在準(zhǔn)備做的事情，給大家做一個初步的分享。

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

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

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

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

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

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

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

5. 技術(shù)

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

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

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

三、企業(yè)如何開始實施 DevOps

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

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

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

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

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

四、回顧和展望

最后一塊回顧和展望，前面說了成功實踐 DevOps 的因素有五個。

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

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

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

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

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

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

對于自動化部署平臺我們要關(guān)注運維相關(guān)的體驗，對于 DevOps 平臺關(guān)注研發(fā)測試的體驗，這是大家一定要關(guān)注的，否則很多公司開發(fā)了 DevOps 平臺，最后推廣的時候遇到很多問題，大家覺得不好用，因此處處碰壁，沒有辦法做下一步。

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