黃杰

[摘? ? 要] 闡述了上海財經(jīng)大學在信息化轉型升級過程中遇到的困難和挑戰(zhàn)。調查了DevOps發(fā)展的現(xiàn)狀，以及DevOps在具體落地實施的建設思路以及對組織文化、組織結構的改變。最后結合上海財經(jīng)大學一年多的DevOps應用實踐，證明了其對IT組織與軟件研發(fā)效能的提升。

[關鍵詞] DevOps;開發(fā)運維;軟件交付

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2019. 15. 070

[中圖分類號] TP315;G420? ? [文獻標識碼]? A? ? ? [文章編號]? 1673 - 0194（2019）15- 0157- 04

1? ? ? 引? ? 言

學校信息化建設轉型升級，不僅要快速實現(xiàn)需求，而且要快速發(fā)布上線，并且必須保證業(yè)務可靠、高效運行。為了滿足這些要求，IT 組織需要強有力的流程、技術和人員作為保障。

（1）版本管理不一致，缺少規(guī)范和標準

實際應用開發(fā)中，項目的管理規(guī)范和管理標準是很重要的一個環(huán)節(jié)，如果沒有良好的管理規(guī)范，會對項目的上線迭代周期產(chǎn)生很大的影響。

（2）缺少有效的自動化構建流水線

在實際的應用上線周期中人工占絕大部分，不僅浪費大量項目人員的時間，并且在重復性的工作中，容易產(chǎn)生錯誤。

（3）無制品倉庫，無法有效地進行發(fā)布回滾

在項目上線之后，版本回退機制是非常重要的，在碰到某個問題需要回退到某個版本的時候，版本介質存放倉庫就會顯得非常重要。

（4）缺少有效的自動化測試流水線，單元測試，接口測試、集成測試、性能測試

目前對交付應用以手動用例為主，主要依賴人工測試，通常測試人員未參與需求和設計評審，對業(yè)務缺乏了解，難以設計合理的測試場景，用例編寫時間較長且難以復用。

針對每次全量交付編寫新用例的同時，由于無法識別實際更新內容和影響范圍，需要執(zhí)行所有測試用例（包括組件自身和集成用例），用例執(zhí)行時間長，導致測試效率難以提高。

（5）無法高效地進行代碼質量分析

在項目實際開發(fā)當中，開發(fā)代碼的質量是后期維護和功能擴展的關鍵因素，人為的代碼質量檢測不僅耗時耗力，還容易出現(xiàn)誤判和少判的情況，很難保證高效。

（6）項目管理，集成、測試、交付、運維，各階段分散，無法串聯(lián)

目前上海財經(jīng)大學擁有多套應用運行環(huán)境，環(huán)境與環(huán)境間邏輯上隔離，同一應用在開發(fā)環(huán)境、測試環(huán)境、預發(fā)環(huán)境和生產(chǎn)環(huán)境上架缺乏關聯(lián)，導致所有環(huán)境的部署和上架，都需要運維人員執(zhí)行部署。未建立以應用為單位的發(fā)布計劃，每套環(huán)境上架時間和資源占用時間，缺乏參考依據(jù)，導致最終發(fā)布時間難以控制。

（7）業(yè)務繁多，要求快速上線，頻繁的變更和交付快速性已成為常態(tài)

以往項目建設周期通常在三個月以上，而隨著微應用建設的推進，應用版本的迭代周期會降低待1個月甚至2周，由于迭代周期變短，采用敏捷開發(fā)模式，上線次數(shù)會顯著增加，測試團隊和運維團隊的工作壓力明顯增加，并且很難做到全面回歸，導致應用迭代上線的壓力非常大。

2? ? ? DevOps發(fā)展現(xiàn)狀

DevOps作為一個術語，包含了一組概念，雖然這些概念并不全是新的，但DevOps已經(jīng)演化成了一個在整個技術社區(qū)迅速蔓延的運動。Ops是系統(tǒng)工程師，系統(tǒng)管理員，運維人員，發(fā)布工程師，DBA，網(wǎng)絡工程師，安全專業(yè)人員以及其他各種有關的職務的通稱。Dev被用作開發(fā)人員的縮寫，但實際上它更為廣泛，意味著“所有參與開發(fā)產(chǎn)品的人”，包括產(chǎn)品，質量保證 QA和其他相關工作人員。DevOps是在整個服務的生命周期中，運維和開發(fā)工程師共同參與的，從設計到開發(fā)過程到生產(chǎn)支持的完整實踐。

人們談論DevOps是“開發(fā)和運營協(xié)作”，或者將“將代碼視為基礎設施”，或是“使用自動化”、“使用看板”等許多看似松散相關的內容。所以一定程度上可以理解為DevOps=人+流程+工具+文化。

喬瑋? 等在《DevOps 發(fā)展現(xiàn)狀及趨勢研究》一文中指出：DevOps提出將開發(fā)與運維結合，其持續(xù)部署、持續(xù)交付技術能夠有效提高產(chǎn)品和服務交付能力，幫助企業(yè)提升效能[1]。牛曉玲等在《DevOps發(fā)展現(xiàn)狀研究》的論文中提到：DevOps的目標是加速軟件發(fā)布和部署流程，利用自動化運維工具降低系統(tǒng)出錯的概率，并快速消除宕機和錯誤等的影響，提高企業(yè)對業(yè)務問題的敏捷性，降低IT成本[2]。DORA發(fā)布的《2018 DevOps現(xiàn)狀報告》[3]， 該報告來自全球范圍內各行各業(yè)的1800多名調查者提交了問卷，調查內容涵蓋了云基礎設施、領導力與學習氛圍、交付效能、數(shù)據(jù)庫實踐等等。報告顯示，在2014年時，只有16%的調查參與者表示自己在DevOps團隊。而在2018，這個數(shù)字已經(jīng)增長到27%。根據(jù)《2018 DevOps現(xiàn)狀報告》的軟件交付效能基準，團隊被劃分為三種類型：高效能、中效能與低效能團隊，對團隊的評價取決于他們的總體產(chǎn)出。發(fā)布頻率、變更響應時間、服務恢復時間，以及變更故障率等指標是劃分的參考標準。2018年，報告新定義了DevOps精英級團隊，其中在高效能團隊中的7%可歸為精英級團隊。精英級執(zhí)行團隊在以下幾個方面有著突出的表現(xiàn)：代碼發(fā)布頻率高46倍;代碼提交至發(fā)布的速度快2 555倍，變更故障率少7倍，事故恢復時間快2 604倍。

所以，DevOps能夠實現(xiàn)交付標準化、自動化、智能化。通過工具鏈與持續(xù)集成、交付、反饋與優(yōu)化進行端到端整合，完成無縫的跨團隊、跨系統(tǒng)的高效協(xié)作。

3? ? ? DevOps建設思路

3.1? ?持續(xù)交付全流程管理

將 DevOps 生態(tài)工具按照持續(xù)交付流程與 DaoCloud Services 集成，實現(xiàn)持續(xù)集成、持續(xù)測試、持續(xù)部署、持續(xù)運維、持續(xù)反饋、持續(xù)改進的全流程管理（如圖1所示）。

3.2? ?支持多種模式流水線觸發(fā)，多種類型流水線

流水線支持代碼源變更觸發(fā)、定時觸發(fā)，上游流水線觸發(fā)，實例部署變更觸發(fā)，滿足多種條件下執(zhí)行流水線的需求，同時支持開發(fā)類和測試類流水線，滿足不同用戶的使用場景。

3.3? ?多租戶，多應用，多項目，多角色

多研發(fā)團隊、多服務應用、多項目、多角色管理，更靈活的支撐學校傳統(tǒng)矩陣式項目管理模式向 DevOps 跨職能管理模式轉型。

3.4? ?多集群/環(huán)境統(tǒng)一管理

對接物理機、虛擬化、K8s、DCE等多種類型的集群，并打上相應環(huán)境的標簽，實現(xiàn)代碼從開發(fā)環(huán)境、測試環(huán)境、預生產(chǎn)環(huán)境到生產(chǎn)環(huán)境的交付。

3.5? ?可擴展的流水線

可視化配置，根據(jù)校方需求自行定義，結合業(yè)界最佳實踐，提供自動構建、單元測試、靜態(tài)代碼掃描、代碼安全掃描、鏡像推送等一站式服務，助力DevOps 快速落地。

3.6? ?應用上線流程管理

通過應用的版本管理，記錄每一次變更的相關制品版本和 Release Notes，同時通過發(fā)布單，配合學校內部上線流程，保障應用每一次上線有章可循。

3.7? ?DevOps 生態(tài)工具集成

集成了Bitbucket，SVN，JIRA，Crowd，Jenkins，SonarQube，Nexus，Robot Framework，JMeter，Maven，Gradle，Splunk，上財認證等工具，有效實現(xiàn) DevOps 持續(xù)交付全流程。

3.8? ?可視化看板，持續(xù)改進交付流程

提供租戶下，跨應用、多維度、多層次的 KPI 統(tǒng)計，實現(xiàn)應用發(fā)布和流水線執(zhí)行情況可視化管理，持續(xù)改進交付流程。

3.9? ?DevOps 生態(tài)工具標準化配置

集成Bitbucket，SVN，JIRA，Crowd，Jenkins，SonarQube，Nexus，Robot Framework，JMeter，Maven，Gradle，Splunk，上財認證等工具的標準化配置，最大化工具的價值。

4? ? ? DevOps應用成效與價值

4.1? ?DevOps應用成效

整個DevOps平臺包括四個部分。分別是項目管理、持續(xù)集成與持續(xù)測試、持續(xù)交付、持續(xù)運維與持續(xù)反饋，其平臺全景如圖2所示。

項目管理采用Jira工具來進行需求管理、變更管理以及缺陷管理，適用敏捷的項目kanban進行項目開發(fā)與協(xié)作。

持續(xù)集成與持續(xù)測試有版本管理驅動，自動化的編譯與構建，代碼質量掃描、自動化的單元測試、功能測試，生成制品包上傳到制品倉庫。

持續(xù)部署集成了Jenkins軟件發(fā)布的能力，將制品高效的發(fā)布到三套運行環(huán)境中（集成測試環(huán)境、預發(fā)布環(huán)境、生產(chǎn)環(huán)境）。

持續(xù)運維與反饋，使用Zabbix來監(jiān)控基礎架構與業(yè)務的健康度，使用Splunk收集業(yè)務日志，配合服務臺和服務知識庫進行知識管理，給用戶持續(xù)的優(yōu)良的體驗。

DevOps看板給領導層與各類管理層查看項目情況提供了實時的KPI數(shù)據(jù)，比如項目的故事點數(shù)量，已投入的人天，團隊速率，需求數(shù)量，按時完成率，構建成功率，部署成功率，構建時長，部署時長，單元測試覆蓋率，缺陷密度，發(fā)現(xiàn)bug數(shù)量，技術債天數(shù)，遺漏bug數(shù)量，故事燃盡圖，bug燃盡圖，版本迭代信息等。

4.2? ?DevOps價值

4.2.1? ?組織文化

交付是每個人的事，經(jīng)過DevOps項目的建設，強調團隊之間的溝通、協(xié)作與尊重，在組織與文化方面，讓所有人就目標達成一致，一切都 以更快更好地交付有價值的服務為目標。 在DevOps模式下，開發(fā)、測試、技術運營三種角色需要像一支團隊一樣緊密地協(xié)作。每個迭代都是一個完整的交付周期，每次完整的開發(fā) 、測試、受控、生產(chǎn)才算一次發(fā)布。

4.2.2? ?高度自動化

自動化是一切DevOps項目的核心思維，開發(fā)、測試、運維需要一起優(yōu)化交付過程，自動化構建、自動化部署、自動化測試、自動化運維。 從虛機創(chuàng)建、環(huán)境安裝（EOS、Tomcat、JDK）、應用構建打包、應用發(fā)布、代碼質量掃描到后續(xù)運維，一切皆自動。

4.2.3? ?持續(xù)交付能力

自動化是持續(xù)交付的基礎能力，目標是加速代碼提交到部署上線的過程，主要包括如下幾方面的自動化：構建、環(huán)境管理、應用部署、測 試。 持續(xù)交付的源頭是配置管理，源代碼、依賴、應用、環(huán)境都應該實現(xiàn)配置管理。不僅僅使用了Bitbucket版本控制工具，像更加反向倒逼了 Jira項目管理的規(guī)范性，自建學校獨立的依賴庫Nexus、創(chuàng)建了應用制品倉庫、統(tǒng)一了Maven構建環(huán)境，使得試點項目能夠根據(jù)版本定位Jira問題單、關聯(lián)源代碼、準確知道線上環(huán)境版本號， 統(tǒng)一的版本庫 統(tǒng)一的構建環(huán)境 統(tǒng)一的制品倉庫 統(tǒng)一的依賴管理 統(tǒng)一的代碼質量管理 統(tǒng)一的虛機資源管理 統(tǒng)一的工具鏈自動化流水線。最終實現(xiàn)了Code as a Service。

4.2.4? ?規(guī)范化

制定和落實代碼管理規(guī)范：目錄、版本、分支、提交等 Jira項目管理驅動整個持續(xù)交付能力的運行，倒逼項目管理更加規(guī)范有序。

流程規(guī)范的改進，在原有的ITIL基礎上，增加輕量化的ITSM實踐，明確項目、版本、組件、代碼庫等維護流程和相應規(guī)范，支撐自動化流水線的運行，并使系統(tǒng)都可以快速升級及回滾。

直觀的度量指標，對開發(fā)運維過程進行度量，內建質量。包括構建通過率、代碼質量掃描、發(fā)布成功率等，對每一個環(huán)節(jié)“完成”的標準進行量化，減少后續(xù)環(huán)節(jié)產(chǎn)生問題的概率。

5? ? ? 結? ? 語

整個平臺還有很多需要增強和優(yōu)化的地方：自動化測試方面還需要提升，更高的單元測試覆蓋率，補充自動化的UI測試;應用安全方面需要補充，代碼的安全白盒掃描，應用的安全風險評估等。

通過一年多DevOps平臺的建設，上海財經(jīng)大學初步實現(xiàn)交付標準化、自動化、智能化。通過工具鏈與持續(xù)集成、交付、反饋與優(yōu)化進行端到端整合，完成無縫的跨團隊、跨系統(tǒng)協(xié)作。

主要參考文獻

[1]喬瑋，趙文瑞. DevOps 發(fā)展現(xiàn)狀及趨勢研究[J]. 數(shù)字技術與應用， 2018（4）： 40.

[2]牛曉玲， 吳蕾. DevOps 發(fā)展現(xiàn)狀研究[J]. 電信網(wǎng)技術， 2017（10）： 48-51.