雷濤，DevOps 標準核心編寫專家、Jenkins 全球大使，前百度 DevOps 產品架構師，無人車工程教練。

先后就職于新浪網，摩托羅拉，諾基亞，愛立信，樂視等國內外知名企業。

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

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

一、VUCA 時代如何應對灰犀牛

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

這個概念最早是美軍在20世紀90年代提出來的，引用描述冷戰結束之后的越來越不穩定、不確定的、模棱兩可的、復雜多邊世界的關系，在2001年911的恐怖事件之后這個概念被確定，VUCA被戰略性和商業領袖來描述成為這種新常態的混亂和快速變化的商業環境。

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

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

還有一個原因是科技現在越來越重要，大家都在說科技以無形的資產超越有形的資產。像微軟市值，據說1%都是實體資產，99%是公司代碼。所以說在新型科技上投入越來越多，便會保持領先優勢。

但是這里要提出一點，高科技企業和實體產業中的企業正好相反，對科技的投資是比較謹慎的態度。謹慎態度表現為否認事實避重就輕，得過且過盲目樂觀，聽信一些診斷延誤，推卸責任，同時也缺乏相關的經驗，也擔心引起一些消極的逃避。

客觀原因就是非高科技企業尤其是實體產業的試錯成本通常高于互聯網行業，也有主觀因素，擔心看不懂，學不好學不會。

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

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

[[322822]]

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

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

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

第三，是不要靜止不動。

第四，不要浪費機會，要想辦法把危機轉換成機遇。

第五，站在順風處，最好的領導是在危險還沒有靠近的時候采取行動。

我們發現灰犀牛事件的人，我們要成為控制灰犀牛事件的人，帶領大家躲避相關的風險。

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

因此這里回歸到的正題，給大家分享我們在各大企業中調查研究后總結出來的關鍵因素，這五個因素分別是目標、人員和文化、流程、平臺還有技術。

二、成功實踐 DevOps 的 5 個關鍵因素

1. 目標對齊

第一個關鍵因素是業務目標要對齊。IT的部門通常做了很多事情，為什么業務部門依然不高興？通過了解，業務部門認為有四個方向。

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

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

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

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

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

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

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

我們也了解了一下原因，首先是雙方部門領導的重視，給了大量的支持，還有前期一起進行了相關的敏捷實踐，業務部門一起完成了相關的標準事件，同時請有經驗的人員給業務團隊做相關的指引和培訓，也請了外部的教練來做指導。

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

2. 人員和文化

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

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

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

其實這正好是 DevOps 嘗試要去解決的問題，即如何讓企業內部的開發運維和其他組織高效協作，達到一系列共同的目標，更快、更可靠向客戶還有終端用戶去提交軟件和相應的服務。

所以通常會演變為兩個團隊，以前項目制的團隊通常演變為多功能的產品開發團隊，就像屏幕右下角所示，大家聚集在一起，團隊里面有開發、測試、運維，甚至還有我們的業務人員，在互聯網公司也是叫產品經理，大家一起共同為整個產品和服務的承辦去承擔相應的責任，因此大家的積極性相對比較高，這是一塊。

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

在這樣的背景之下會成立一個新的DevOps平臺團隊，這個團隊一般會負責公司相關產品的整個端到端的工具鏈的貫穿，還有流程和工具的結合相關的工作。

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

另外相信有很多人看到有一些學習型的組織，這樣的組織一般會建議說大家通過相應的組織結構的轉變，人員團隊之間相互學習，通過重組的方式充分釋放團隊和人員的力量。

之前的模式主要是分層特別明顯的組織架構，從控制型轉變為虛擬化或者網絡狀的組織，達到相關的事情對齊，還有足夠的授權方式，因此之前可能是謙虛合作的模式，后續可能是大家形成一個高度合作的小組去承擔整個產品的承辦。

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

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

經過和相關的管理者做商量和討論，我們就用學習型組織的建議，比如說建立共同的愿景，團隊一起學習，同時逐漸改變團隊的模式，最后從系統化思考怎么樣優化這些事。最后我們想到一個辦法，就是說設置一個輪崗，輪崗的目標就是增進團隊的協作，最終達到上線。

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

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

3. 流程

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

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

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

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

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

4. 平臺

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

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

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

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

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

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

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

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

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

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

最后還有一個關于自動化，它的三個前提條件非常關鍵，第一是標準化，一定要做標準，要在相應的流程和規范的梳理，只有形成流程和規范的標準，才能用腳本實現，這樣實現之后才有自動化，那后續相關的維護和功能的拓展才有相關的版本化的管理方式。

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

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

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

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

另外變更覆蓋率，測試覆蓋率，測試健康度的檢查，同時還有公司會做CI/CD的免測率，會根據免測率的情況給你的產品質量打分，你產品質量相關的分數越高，免測率越高，類似于國家提出的質量免檢的手段，這樣會更加有利于產品開發團隊去不斷提升他們內部的質量，同時要不斷解決我們的技術棧，關注于質量或者開發提交的打回率，做到有問題及時發現。

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

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

首先度量體系的目標我們是要打造一個相關的度量平臺，同時對生產率、交付質量、速度、滿意度提出一個可視化的展示，所以度量指標的意義就是能幫助我們全面評估我們 DevOps 相關實踐落地的情況，同時根據這樣的可視化的體系，能夠給我們合理指引我們哪里做得好，哪里做得不好，哪里還沒有開始，同時達到一個快速達成，不斷做持續相關優化改進的事。

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

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

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

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

最上面這個度量體系分為三個維度，個人、團隊和系統，對于個人來說這一塊最常用的場景就是工程師畫像，大家用得比較多，這個通過個人的經驗、能力、專業知識、意愿和工作來做相應的模型，再結合相關工程師的過去、現在、未來做相關的計算、學習，得出一些相應的數據。團隊這一塊是充分利用每個團隊里面工程師人員，各種角色，同時對于團隊所承接的業務或者產品的復雜度、收益做綜合的計算，畫出團隊的畫像。

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

5. 技術

第五個關鍵要素就是技術，大家應該非常關注，從開發的模式的轉變、應用架構的轉變還有打包，還有托管機房的轉變，都逐漸轉換到 DevOps 微服務、容器和云化。

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

最后關于技術這一點大家通常會忘記一個非常關鍵的點就是我們跑得太快沒有功夫或者沒有時間修我們的技術棧，這一點非常關鍵，導致你的系統跑到一定的程度會產生大量的問題，所以在技術這一塊給大家重點強調，我們一定要定期修復技術棧。

三、企業如何開始實施 DevOps

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

對于工具系統這一塊，我們人員的擴張之后勢必會產生大量的工具系統，是技術的不斷迭代，有一些團隊可能會積極引入新技術，那復雜的系統我們應該如何考慮，怎么推廣 DevOps，DevOps 對于復雜的場景是否還有效？我們是否應該尋找一些幫助？比如說對外去尋找一些咨詢的力量，對內向其他做的好的部門取經，因此我們強烈建議，通過這種方式，我們左手是用 DevOps 的標準，右手是 DevOps 平臺，通過兩手開展 DevOps 相關實踐的落地。

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

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

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

四、回顧和展望

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

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

對于后續的展望，目前業界也做了大量的討論，就是主要我們認為幾個方向是在DevOps相關的展望是在以下幾個方面：

第一是項目到產品的研發模式。

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

第三是新的部署模式，一般是開發部門做，最后執行上線的時候雖然是在某一個 DevOps 平臺里面做上線，但是這個時候依然是由運維人員做執行上線，后續我們覺得會逐漸轉變為自助平臺建設越來越完善，因此提供足夠的監控和相關的審計功能，這樣當我們的項目制到產品制之后，產品開發團隊就完全可以做到自助式的變更流程，甚至說代碼提交，通過各種自動化的有效檢測手段自助上線了。

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

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

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