切忌一步到位，談談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落地實施路徑的規劃原則，你們能夠做爲參考。