切忌一步到位，談談DevOps實施落地

2020年6月19日，由雲端計算開源產業聯盟指導，高效運維社群和 DevOps 時代社群聯合舉辦的GNSEC 2020線上峰會圓滿舉辦。BoCloud博雲參加了本次峰會並分享了博雲幫助客戶實施DevOps的真實案例，以及博雲內部推行DevOps落地的實踐經驗。

01

DevOps範圍、願景和目標

過去我們談到DevOps的時候有很多不同的認知。早先說DevOps可以是CICD，持續交付，後來有人把敏捷開發管理放進來，之後有客戶跟我們聊DevOps是指運維SRE。得利於中國資訊通訊研究院主導的研發運營一體化的標準，終於把DevOps包含哪些內容給說清楚了，如下圖所示：

DevOps 標準 中主要包含5大塊 內容：研發運營一體化、應用設計、安全積極風險管理、組織架構、系統工具。核心的模組 在第一 部分“研發運營一體化過程”裡，而且標準中把最佳實踐是什麼樣、不同等級實踐對應有哪些具體細節都說的很清楚。

 

基於如上這個框架，實際上可以看到DevOps的目標是很多的，涉及開發、測試、運維三個模組。

 

因為目標很多， 所以DevOps到底要怎樣落地？是不是照著藍圖做就能很好的實現DevOps落地？因為有藍圖有最佳實踐、有標準，按理說DevOps落地應該是非常輕鬆的。我們回答也很明確：不是這樣的。這裡我舉2個例子，管中窺豹的看看DevOps實踐過程中的一些彎路。

02

照著藍圖做，是否就能輕鬆DevOps落地？

第一個是大型央企DevOps推廣案例：內部雲團隊想規劃建設PaaS平臺，包括DevOps平臺，因為PaaS包含DevOps，所以雲團隊想將PaaS平臺中的DevOps能力推到研發部門。

整體建設範圍是敏捷開發管理、持續交付管理、運營一體化，這個事情花了很多精力，也做了很多內部團隊的溝通，整體來講在業務團隊推廣效果不是特別好，後來就逐漸擱置了。這個事情不是說做失敗了，至少效果沒有顯現出來。總結來說的話： DevOps平臺應該是誰使用誰建設可能在起步階段會更容易一些。

第二個是我們某個中型金融機構案例。這個案例建設目標起的比較高，並找了諮詢公司做了諮詢。諮詢公司做的東西確實比較好，比較完整也比較細緻。整個的建設目標包括開發管理、持續整合、測試部署、持續監控的，規劃的很完整。

到了落地階段，這個專案整個落地週期10個月，上線7套系統。整個落地模組包含專案協同，流水線製品庫等等，落地了專案協同、CICD流水線、度量儀表盤、管理駕駛艙。客觀說實際推廣效果還是可以的，尤其開發團隊感受還可以。但是整個專案後來總結時運維團隊提出了很多意見，說前期運維團隊也參與了，領導也提了目標要求，但最後做了10個月，運維團隊沒有感受到這個平臺帶來價值。

這個實際應該算是比較成功DevOps專案，但是後來評估的時候運維團隊卻提出了明確的負面意見，影響了專案評價。總結來說： 專案前面調起的太高，範圍過大，各個團隊落地的期望比較高，但是實際上落地的時候可能有些團隊沒有得到想要的效果，效果評價受到了影響。DevOps落地初始目標設計，要更合理一些。

如上兩個小案例，以點帶面說明下DevOps落地的典型問題。

基於前面的案例，我想回答一下為什麼DevOps藍圖很難一步到位 。第一是因為組織架構， DevOps專案希望同時在開發部門、測試部門和運維部門都得到很好效果很難，最好分步來做，先解決單部門問題是比較合理。

第二個DevOps自動部署的工具僅僅是一部分，其實還涉及DevOps文化和共同認識的建立過程，這需要一個較長的過程。 DevOps整體藍圖要解決的問題，涉及的底層工具非常多，很難短時間在沒有很好的基礎前提下快速落地， 良好的DevOps落地需要一系列標準規範的推廣落地 。但一般來說，因為歷史包袱原因，標準規範的推廣需要一個逐步甩包袱的過程。這些規範非常需要，但是因為歷史包袱問題推廣是很麻煩，遇到業務部門業務需求是很大的，所以說標準規範推廣是比較難，但必須要做，但是推廣需要過程。整體來說，這幾個原因是DevOps有了藍圖和最佳實踐還是很難一步到位原因。

03

DevOps落地實施路徑建議

 

DevOps具體實施有哪些好的實施路徑，我們也想嘗試回答一下。理論上從DevOps每個領域都可以發起DevOps，然後去落地，而且根據不同公司情況、業務基礎設施情況，實施路徑可能不同。根據我們的落地案例，我們嘗試性的找幾個比較通用合適的實施路徑，舉幾個例子跟大家分享一下。

第一個國內某股份制銀行，他的推廣路徑首先是在研發過程管理中，敏捷開發管理、配置流水線、度量；然後在運維視角釋出自動化、變更管理自動化；後來緊隨著整個前期的研發推廣，同時在底層專業平臺、專業資料庫管理中建立容器化。

從開發測試角度：他們的流水線已經大規模應用，所有開發團隊在開發第一步就可以把流水線建立好，開發人員只基於流水線就可以做整個CI和CD上線，是非常有價值的事情。另外，敏捷開發管理也已經落地到了整個研發流程管控裡（這個行業經驗很多，但是對開發測試來說，也是最重要的）。

從底層能力方面：容器化大規模應用，對於CICD非常有幫助的。

目前呢，他們正在推進DevOps能力整合最佳化，實現更大價值。這個案例應該說是非常好的DevOps實踐路徑。尤其是已經大規模推廣起來了，是非常厲害的。

第二個是安信證劵。第一步做了敏捷開發和自動化測試和度量，主要在開發側；在運維視角做了容器化，也已落地。然後安信證券比較好的一點是除了推廣和落地，在於很好選擇了試點團隊。

試點團隊選擇了技術能力比較強，希望能夠快速釋出，根據這幾個點選了幾個團隊進行試點，進行專案實踐，整個試點達到比較好的效果。第一，已透過DevOps三級認證。第二，流水線真正標準化落地，度量指標及指標指導下研發改進效果明顯。第三，目前已經啟動了大規模推廣。是DevOps比較好的落地，並能夠達到設計效果的一個專案。

第三個是我們自己博雲。其實我們做DevOps時間挺長，我們內部2018年開始推行DevOps，當時也是透過工具鏈來做。後來我們做了自己的DevOps平臺，目前已經全部切換到自己的平臺來用了。推廣路徑如上圖，自研DevOps平臺推廣週期相對比較短，基本上4個月就全部切換過來了，主要是因為內部在工具鏈使用方面已經有比較多的經驗。

我們是軟體公司，沒有所謂線上釋出這個過程，所以說DevOps落地更多集中在研發測試環節。我們的需求本身是比較明顯， 有兩個核心需求，第一個實現快速迭代釋出，第二個實現能夠更好去把研發進度效率實現自動化，把度量的事情搞定 。路徑上來說，我們首先DevOps團隊自己先去試點推廣，DevOps產品現在整體來說1個月一次正式的版本釋出，進度質量效率數字化，實時可見。第二個透過公司管理層的直接推進快速擴充套件到全公司研發團隊。

實施路徑選擇建議

 

嘗試性的總結下DevOps實施路徑選擇原則。

第一個要制定合理目標。 核心原因是每個團隊最為關注目標是不太一樣的，像剛剛講到我們作為做軟體的公司，更多偏向於快速迭代釋出和度量這兩塊的內容，但作為一個線上系統可能更重要是別的一些指標，所以說基於自己現狀從核心痛點出發，制定合理專案目標比較重要，同時在運維釋出和CICD流水線都有需求。

 

第二個是管理好內外部期望。 其實我們一開始要提出自己的目標，一個方面要有很好價值，另外也不要好高騖遠，不要把期望搞的很高，推廣是沒有那麼容易，要有合理期望值，包括領導，期望太大容易失望，失望了之後推廣就失敗了。

 

第三個是系統設計取決於組織架構。 最好不要一上來做組織架構的事情，這個肯定可以做，但是比較麻煩。在DevOps實踐裡面組織內部做的事情很多，可以從本身組織開始，然後逐步實現整合跨部門，這個很合理。除了平臺之外還有人的文化認知， 所以 分步實施、逐步演進，也不需要規劃一步到位， 一個月就把DevOps做到位，這個其實不太現實。一步到位非常難，而且效果不好。那麼試點團隊是先試點，配合比較好、意願比較強再去推廣，這個是幾乎所有DevOps做得比較成功企業的工程實踐。

 

另外一個週期上要有持續的推進機制， 可能剛開始大家推進挺好，那麼過了半年推廣是不是忘了，必須要有持續的推進機制，要有打持久戰的準備，逐步把DevOps這事落地最佳化到最好。

 

最後一個是：規範。 越規範越有用，規範價值是非常大的。在可能情況下可以先推行規範，有了規範，很多事情會變得非常容易，而且對於使用者，落地之後的使用體驗也會很好。所以規範越早推越好。

整體上這個就是DevOps落地實施路徑的規劃原則，大家可以作為參考。