DevOps開發運維的一套方法論。這邊文章主要借鑒萬達的DevOps的建設過程。談談DevOps主要解決那些問題和怎么解決。

DevOps的是一種IT項目開發管理方法論，它旨在提供全面的持續集成、持續交付等能力，并持在續進行過程度量和改進，不斷提升 IT 運行效率。

問題背景：

傳統的管理方式很難高效率、高質量的進行管理和把控較多的的產品線和項目，人肉運維成本越來越高。并且隨著虛擬化、容器云、微服務等技術的發展，應用底層的運行環境愈發多樣化，物理機、虛擬機、容器云三種異構環境、移動應用、Springboot 應用、純前端應用等數十個異構應用都需要通過一個平臺進行統一的部署和管理。

DevOps 達成的目標：

1.通過 DevOps 平臺統一管理所有產品、項目，對團隊、對人能進行數字化的考核。

實現所有應用的持續集成、100% 自動化部署，提升應用的軟件交付效率。

如何實施：

從邏輯上把 DevOps 平臺劃分為三大領域：敏捷過程、持續交付、持續改進。

敏捷過程針對于軟件過程進行管理，包括產品、項目、團隊、計劃、任務等，持續交付則關注從需求到上線交付的管理，包括持續集成、自動化測試、自動化部署、交付流水線等。持續改進則體現了平臺的核心價值，不斷的度量和優化軟件過程，為提升 IT 運行效率打下堅實的基礎

在上面三大領域的基礎上，又做了一些模塊拆分，平臺的邏輯架構如下：

DevOps 平臺劃分為領域層、基礎服務層、工具層三層。工具層封裝了一些開源工具，提供基礎能力。服務層在此基礎上封裝的一些基礎服務，如編譯、部署、代碼管理等。領域層主要包括項目管理、產品管理、構建、部署、交付流水線、度量優化等模塊。底層運行環境支撐物理機、虛擬機、容器云平臺。

產品管理& 項目管理

軟件的整個生命周期可以從不僅僅是項目的生命周期，而是應該也包括了產品的生命周期。在企業內部，通常我們先決定做哪個產品，然后需求調研、版本劃分，確認了具體版本要實現的需求范圍后，便可以組建項目進行研發。研發完成進行交付后，有進入產品的線上運營階段。直至產品下線。一個產品可以對應多個項目，當然，對于有些企業而言，一個項目也是持續穩定的維護一個產品。

持續集成

持續集成模塊功能主要有代碼庫管理、構建定義管理以及構建實例管理等。在構建定義管理模塊中，DevOps 平臺將構建任務分成了四種類型：

• 編譯類任務：Maven、Ant、Gradle、純前端構建等

• 測試類任務：Sonarqube、Jmeter、Selenium等

• 打包類任務：Npm、Archive、Docker 等

• 其他工具類任務：Copyfile、Shell、介質提交到Nexus 倉庫、介質上傳二方庫等。

在每個構建定義上可以選擇若干個需要的構建任務，通過原子步驟編排，組裝成一個完整構建流程。代碼提交時觸發構建（支持 gitlab、github、svn 等常用代碼庫版本管理工具）、日構建等不同的構建觸發策略等支撐了持續集成的完整鏈路打通。

自動化部署

在自動化部署模塊中，為了更好的與實際結合，我們將部署分為三個階段：設計、轉換、運維。

設計階段： 將部署架構分為三層：部署裝配（Assembly）、部署容器（Platform）、部署組件 (Component)。部署裝配是對部署架構的描述，由多個部署容器組成，每個部署容器由若干個部署組件組成。

轉換階段： 將部署架構與部署策略（全新、藍綠、灰度、滾動升級等）、資源（具體資源如物理機、虛擬機、容器）、組件配置參數（端口號、JVM 參數、健康檢查 url 等）進行結合，生成部署計劃，一鍵執行自動化部署。

運維階段： 對于已部署的實例進行運維管理，包括啟動、停止、重啟、修復、狀態檢查等等。

持續交付流水線

為什么需要持續交付流水線？舉個例子來說，我們常常苦惱最終上線版本和系統集成測試環境不一致。這一般是因為在系統集成測試完成后發現了問題，作了代碼變更但沒有重新構建，而是直接在介質里進行了調整進而發布上線。在持續交付流水線中是不允許這種情況出現的。所有上線入口一定是最初的構建，所有的后續產物都是基于這一介質，如果有變更必須重走流程。這樣可以保證發布的安全性和統一性，線上出現問題也是可以追溯的。當然過程中的環境可以配置人工介入或自動執行。

發布流水線從構建到生產部署共 9 大環節，涵蓋 SIT/UAT/LAB/PROD 四大環境。驅動了開發、測試、質量、運維等多個角色的協作。

在設計流水線能力時，我們主要考慮到幾點：

• 結合企業的不同交付流程，要能支持自定義的流程配置，要能支持多套流程配置

• 流程的每一個環節都要支持自動執行的配置

• 流程中每個環節的屬性和配置信息可以自定義，靈活擴展

• 流程以構建開始，讓 buildNumber 貫穿整個流程，方便追根溯源

• 要有一個看板，直觀的看到整個產品的版本目前到了流程的哪個環節，是 SIT 還是 UAT，結果如何

• 要有一個看板，直觀的看到每個環境下，有哪些介質在運行

以這些為基礎準則，我們底層基于了我們的 BPS 流程引擎，支撐流程的自定義和擴展。并且，針對于每個環節，都可以配置前置后置事件、人工執行還是自動執行，責任人等。整個流水線從構建開始，保證全局介質唯一，避免人為修改介質導致的生產介質不可追溯。

在交付看板上，環境看板和發布看板如下

度量優化

精益運營的基礎是度量，度量的三大維度：指標、執行監控、預測。首先是明確指標和執行監控，基于軟件全生命周期的度量過程中企業遇到的最大困難莫過于拿不到完整的數據，各個部門、各個流程、各個系統之間數據相互隔閡，信息很難流通，導致無法從整體的角度對軟件過程進行度量。當 DevOps 平臺能打通企業的軟件生產全生命周期時，數據的割裂性問題自然也就不存在。當然，度量不僅僅是事后的統計分析，更應該提供過程監控的能力，在過程中，通過一些看板（比如任務看板、需求看板、發布看板）、趨勢圖（比如任務燃盡圖、bug 燃盡圖）等，提前預知風險，規避風險，持續把控項目質量和產品質量。

難點1：統一流程和規范

回顧一下前文的發布流水線的介紹，其實這其中我們在介紹時省略了大量的細節。比如，在開始構建時是否要打一個 Tag，此時針對構建介質產物是否不應該是 snapshot 版本，而應該是 Stage 預發版本。如果 UAT 等測試通過之后，這個介質版本即為可發布版本，此時介質需要轉移到 Release 版本的介質倉庫。這就是一個完整的流程，也是需要加入到規范中去的。

梳理企業的流程和規范是企業建設 DevOps 的前提，甚至即使不建設 DevOps 平臺，這也是一個必不可少的行為。只有統一了企業的流程和規范，才能建設出一個適用于企業的 DevOps 平臺，否則到最后，有可能會讓 DevOps 平臺脫離實際，導致沒有人會去使用。

我們在建設過程中，每一個模塊都需要結合萬達的流程規范以及我們的最佳實踐共同進行建設，在前期，當一些流程規范不是那么明確的時候，還需要一起討論，同時規范也不是一蹴而就的，實施過程中發現一些不合適的地方就需要進行修改，這也就帶來了需求的反復的可能。以持續交付流水線為例，這個就需要結合萬達的環境、發布規范來定制流程，對于其他企業而言，持續交付流水線未必就是這樣的一個流程，有可能會少一些環境，也有可能多個預發環境，又或者會把這一個流水線拆分成多個流水線。

難點 2：異構兼容

對于應用運行環境而言，需要同時支撐物理機、虛擬機、容器云、Android 設備、IOS 設備多種類型的環境。而應用本身又分為純前端應用、SpringBoot 應用（Fat JAR）、傳統應用（WAR）、Android、IOS 等各種類型。這就對自動化部署框架提出了很高的要求，一套架構要能同時支撐異構應用部署在異構環境上。

以移動應用的自動化部署為例，os 部署組件可以用來區分系統、computer 可以用于校驗機型。選擇部署資源時，從 cmdb 中導出項目的移動設備資源，最后將應用自動化部署到移動設備上。

難點 3：職能切面

DevOps 平臺建設之前，企業可能已經有不少系統了，比如云資源管理平臺、容器云云平臺、自動化測試平臺、統一監控平臺等等。那么很多時候一個困難點就在于 DevOps 的定位了，在測試的能力上，DevOps 平臺要不要完整的把測試的能力都管理起來呢？在自動化部署的時候，要不要直接創建虛擬機對資源進行操作呢？我們在萬達落地 DevOps 的過程中，也遇到了這些問題。我們認為：

• DevOps 無法讓每個人的工作都在上面，高級能力還是專人在專業系統上完成；

• 如果專業系統足夠自動和自助化，可考慮逐步納入 DevOps 平臺

• 我們做的是工程效率平臺，不是給多個系統做個統一門戶

本著這些理念，我們就明確了對職能的切分。像對底層資源的管理，是統一通過 CMDB 進行管理，DevOps 只是進行資源的申請與使用。在測試環節，則是對接自動化測試平臺，將持續交付流水線中的測試環節拉起來，保障整個流水線的完整。在對已部署應用的監控，可以對接企業的統一監控平臺進行健康監控。

總結

以上是生活随笔為你收集整理的JAVA开发运维（DevOps过程）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。