黃 靜，陳秋燕，姚東烽

（1.中國移動通信集團廣東有限公司，廣東 廣州 510640；2.浪潮世科（山東）信息技術(shù)有限公司，山東 濟南 250000）

0 引言

隨著業(yè)界IT技術(shù)的不斷發(fā)展以及企業(yè)園區(qū)信息化應(yīng)用系統(tǒng)不斷增多，且各應(yīng)用系統(tǒng)采用的技術(shù)架構(gòu)及開發(fā)平臺差異較大，對于這些應(yīng)用系統(tǒng)的持續(xù)優(yōu)化、擴容及維護都要花費較大的投資和成本。通過在微服務(wù)PaaS平臺構(gòu)建DevOps流水線，能夠?qū)崿F(xiàn)敏捷開發(fā)及自動化部署、運維一體化的流程，實現(xiàn)從多個角度對業(yè)務(wù)系統(tǒng)進行自動化運維監(jiān)控，從而實現(xiàn)信息化應(yīng)用的全生命周期無縫管理及自動化的高可用保證。

1 DevOps介紹

1.1 定義

DevOps源于“Development（開發(fā)）”和“Operation（運維）”兩個詞的縮寫，軟件開發(fā)和IT運維的結(jié)合被稱為DevOps。DevOps是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件行業(yè)日益清晰地認識到：為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)和運營工作必須緊密合作。[1]

從定義中可以看出，可以明確DevOps這個過程參與的人員主要是開發(fā)團隊和運維團隊，而DevOps的目的是在兩個團隊之間，建立良好的溝通和協(xié)作，更快速、更可靠的創(chuàng)建高質(zhì)量軟件。

1.2 開發(fā)模式對比

瀑布模式是最早出現(xiàn)的軟件開發(fā)模型，由于這種模型的線性過程太理想化，在現(xiàn)代業(yè)界的軟件開發(fā)中，瀑布模式幾乎不復存在。而同樣作為傳統(tǒng)模式的迭代式開發(fā)和螺旋開發(fā)，是在瀑布模式的基礎(chǔ)作出調(diào)整和改良的軟件開發(fā)模式，在現(xiàn)時某些特地場景有其一定的適用性。

現(xiàn)代最流行的是敏捷管理模式，敏捷開發(fā)不追求前期完美的設(shè)計、完美編碼，而是力求在短期內(nèi)開發(fā)出產(chǎn)品的核心功能，盡早發(fā)布出可用的版本，然后在后續(xù)的生產(chǎn)周期內(nèi)按照新需求不斷迭代升級，完善產(chǎn)品。

DevOps是最新近才出現(xiàn)的，它是將運維納入產(chǎn)品開發(fā)過程的思維方式，是敏捷的有效補充，它通過消除資源浪費和簡化部署等方式來實現(xiàn)這一目標，從而實現(xiàn)更快，更持續(xù)的生產(chǎn)部署。

瀑布模式 敏捷模式 DevOps相似點 三者都有軟件開發(fā)、測試和部署這三個階段。但前者嚴格按照線性方式進行，而后兩者追求快速開發(fā)軟件，適合經(jīng)常變化的項目。不同點1、將軟件生存周期的各項活動規(guī)定為按固定順序而連接的若干階段工作，階段之間產(chǎn)生大量的文檔，不適應(yīng)用戶需求的變化。2、由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風險；1、簡化了傳統(tǒng)開發(fā)管理的繁瑣流程和文檔，假設(shè)和擁抱不確定性，認為需求變更是客戶需求的一部分，強調(diào)適應(yīng)性和團隊中的高度協(xié)作；2、敏捷方法在運維方面沒有敏捷實踐的速度，開發(fā)和運維之間缺乏協(xié)作仍然會減慢開發(fā)過程和發(fā)布；3、敏捷流程在三個階段之后會終止。1、DevOps幾乎擁有敏捷開發(fā)模式的一切優(yōu)點；2、DevOps方法是基于對更好的協(xié)作和更快的交付的需求而產(chǎn)生的；3、D e v O p s包 括 后續(xù)持續(xù)的運維，即DevOps會持續(xù)的監(jiān)控軟件運行情況和進行持續(xù)的開發(fā)。

1.3 傳統(tǒng)軟件開發(fā)方式和DevOps方式之間的區(qū)別[2]

二者的區(qū)別主要在于開發(fā)和運維的模式上，如下所述：

傳統(tǒng)方式 DevOps 1.傳統(tǒng)上在軟件開發(fā)中（無論是瀑布模型還是敏捷方式，敏捷也比較傳統(tǒng)），都由“開發(fā)團隊”來構(gòu)建軟件。2.開發(fā)團隊需要與運維團隊進行了大規(guī)模的“交接”。運維團隊負責執(zhí)行一系列“部署”活動，將軟件代碼移至生產(chǎn)環(huán)境，并負責維護后續(xù)的系統(tǒng)穩(wěn)定運行。3.生產(chǎn)環(huán)境的基礎(chǔ)設(shè)施與開發(fā)或測試不同。4.需要有額外檢查和平衡，以確保它一切功能正常。DevOps打破了開發(fā)和部署之間的界限，實現(xiàn)開發(fā)運維一體化：1. 支持持續(xù)集成（CI），開發(fā)人員提交了新代碼之后，立刻自動的進行構(gòu)建、（單元）測試。2. 支持持續(xù)部署（CD），當交付的代碼通過評審之后，自動部署到生產(chǎn)環(huán)境中。3.自動化了所有測試用例，所有的配置管理、環(huán)境管理和發(fā)布管理，可以直接launch。

2 DevOps生命周期及其相關(guān)工具

一般來說，DevOps由多個階段組成：持續(xù)開發(fā)、持續(xù)測試、持續(xù)集成、持續(xù)監(jiān)控、持續(xù)部署，這些階段統(tǒng)稱為DevOps生命周期。這五個階段能體現(xiàn)DevOps從”需求提出-＞生產(chǎn)-＞完整交付”的整個開發(fā)流程，下面對DevOps生命周期的階段性進行分析。[3]

2.1 持續(xù)開發(fā)

DevOps生命周期的第一個階段是編碼和構(gòu)建。開發(fā)應(yīng)用程序源代碼的第一步是從不同的編程語言中進行選擇，諸如JavaScript，C / C ++和Python等。而維護代碼的過程稱為源代碼管理（SCM），可使用Git和SVN等工具來維護不同版本的代碼，以及使用Gradle，Maven等類似工具來構(gòu)建/打包代碼到可執(zhí)行文件中。

與瀑布模式不同的是，軟件可交付成果被分解為短開發(fā)周期的多個任務(wù)節(jié)點，在很短的時間內(nèi)開發(fā)并交付。這是DevOps生命周期中一個不斷進行軟件開發(fā)的階段。

2.2 持續(xù)測試

在這個階段，對開發(fā)的軟件進行持續(xù)的Bug測試。TestNG，Selenium和JUnit是常用于自動化測試的一些DevOps工具，這些工具允許質(zhì)量管理系統(tǒng)完全并行地測試多個代碼庫，以確保功能中沒有缺陷。通過自動化測試，可節(jié)省開發(fā)人員手動測試浪費的時間和精力。在這個階段，使用Docker容器實時模擬測試環(huán)境。一旦代碼測試通過，它就會被重新發(fā)送到持續(xù)集成階段以更新源代碼。

2.3 持續(xù)集成

這是支持新功能的代碼與現(xiàn)有代碼集成的階段，是整個DevOps生命周期的核心。軟件在不斷地開發(fā)，源代碼在頻繁地更改，更新后的代碼需要不斷地集成，并順利地與系統(tǒng)集成，以反映對最終用戶的需求更改。更改后的代碼，還應(yīng)該確保運行時環(huán)境中沒有錯誤，允許我們測試更改并檢查它如何與其他更改發(fā)生反應(yīng)。

Jenkins是被廣泛應(yīng)用的可靠的持續(xù)集成工具，用于獲取更新的源代碼，并生成一個構(gòu)建，最終可以部署到測試或生產(chǎn)環(huán)境。 這些轉(zhuǎn)換是無縫進行的，更新的代碼將打包并進入下一階段，即測試或生產(chǎn)服務(wù)器。

2.4 持續(xù)部署

在此階段，最終確定的應(yīng)用程序代碼將被部署到生產(chǎn)環(huán)境。配置管理是這一階段的關(guān)鍵過程，它將應(yīng)用程序代代碼發(fā)布到服務(wù)器，為所有服務(wù)器安排更新，確保應(yīng)用程序性能和功能條件在整個生產(chǎn)過程中保持一致。Puppet，Chef，SaltStack和Ansible是用于配置管理的一些有效的DevOps工具，用于執(zhí)行新代碼的快速和連續(xù)部署。

需要注意的是，如果添加了任何功能或引入了新功能，我們應(yīng)該準備好迎接更多的網(wǎng)站流量。

容器化工具在部署階段也發(fā)揮著重要作用。 Docker和Vagrant是流行的容器化工具，這些工具有助于在開發(fā)，測試，登臺和生產(chǎn)環(huán)境中實現(xiàn)一致性。 同時，它們還可以處理連續(xù)部署的可伸縮性。

2.5 持續(xù)監(jiān)控

這是DevOps生命周期中非常關(guān)鍵的階段，持續(xù)監(jiān)控旨在保持應(yīng)用程序中服務(wù)的可用性。在此階段，IT運維團隊比開發(fā)團隊的參與程度更高，他們監(jiān)視用戶活動、檢查系統(tǒng)是否有異常行為以及跟蹤錯誤的存在。一些常見系統(tǒng)錯誤如“服務(wù)器無法訪問”或“內(nèi)存不足”可以在這個階段被發(fā)現(xiàn)和解決，它還能確認重復出現(xiàn)的系統(tǒng)錯誤的威脅和根本原因。

這也可以通過使用專用監(jiān)控工具來實現(xiàn)，Splunk，ELK Stack，Nagios，NewRelic和Sensu是用于持續(xù)監(jiān)控的關(guān)鍵DevOps工具。這些工具可幫助密切監(jiān)視應(yīng)用程序和服務(wù)器，主動檢查系統(tǒng)的運行狀況。在這些工具的幫助下，可以提高生產(chǎn)率和應(yīng)用程序的可靠性，從而降低IT支持成本。當在此階段檢測到重大問題時，可以向開發(fā)團隊報告，以便可以在持續(xù)開發(fā)階段進行修復。

這些DevOps階段連續(xù)循環(huán)進行，直到達到所需的產(chǎn)品質(zhì)量。下圖顯示了在DevOps生命周期的各個階段所使用的工具。

3 Pass平臺+DevOps

DevOps的實施往往需要在一個完整的DevOps過程支撐平臺基礎(chǔ)之上，將研發(fā)過程管理、持續(xù)交付和技術(shù)運營全部融合到一起，同時底層開發(fā)基于微服務(wù)開發(fā)框架，組件運行依托在容器化PaaS平臺上，形成一個完整的整體。[4]PaaS平臺+DevOps是使用微服務(wù)架構(gòu)在 PaaS上建立應(yīng)用程序使得開發(fā)人員與運營之間的協(xié)作更加無縫。PaaS產(chǎn)品充分利用了容器，提供了正確的標準化以簡化部署管道，當這一點與構(gòu)建和部署微服務(wù)的小團隊協(xié)作優(yōu)勢相結(jié)合時，就能夠?qū)崿F(xiàn)DevOps利益最大化。

微服務(wù)、容器、PaaS和DevOps的組合具有巨大潛力，能夠?qū)⒋笮推髽I(yè)信息技術(shù)進行轉(zhuǎn)型，能夠協(xié)助企業(yè)進行研發(fā)管理過程的規(guī)范化和流程化，再進一步實現(xiàn)自動化。

4 結(jié)束語

微服務(wù)PaaS平臺構(gòu)建DevOps流水線，通過采用敏捷開發(fā)模式，能夠明顯提升開發(fā)的效率，支持適度的需求變更，支持持續(xù)的CI/CD，更好地提升軟件系統(tǒng)的易用性及友好性，同時提升運維效率。