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

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

問題背景：

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

DevOps 達成的目標：

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

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

如何實施：

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

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

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

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

產品管理& 項目管理

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

持續(xù)集成

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

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

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

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

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

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

自動化部署

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

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

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

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

持續(xù)交付流水線

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

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

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

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

• 流程的每一個環(huán)節(jié)都要支持自動執(zhí)行的配置

• 流程中每個環(huán)節(jié)的屬性和配置信息可以自定義，靈活擴展

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

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

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

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

在交付看板上，環(huán)境看板和發(fā)布看板如下

度量優(yōu)化

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

難點1：統(tǒng)一流程和規(guī)范

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

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

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

難點 2：異構兼容

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

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

難點 3：職能切面

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

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

• 如果專業(yè)系統(tǒng)足夠自動和自助化，可考慮逐步納入 DevOps 平臺

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

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

總結

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

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