1、DevOps 理念解析及行業(yè)應(yīng)用2摘要DevOps概念解析：DevOps（開發(fā)運維一體化）不僅包含一系列軟件工程相關(guān)的軟件工具，還涉及到 企業(yè)文化、團隊協(xié)作流程等多個方面。從工作流的角度，DevOps包含規(guī)劃、開發(fā)、運維三個部分，可 以基于應(yīng)用設(shè)計、敏捷開發(fā)、持續(xù)交付和監(jiān)控運維四部分流程來理解。相較于其前身敏捷/精益開發(fā)， 開發(fā)人員透過容器向運維側(cè)滲透、打通傳統(tǒng)IT工作中開發(fā)/運維的矛盾和溝通障礙是DevOps的核心進步。DevOps企業(yè)實踐：由于DevOps的實踐遠不僅限于安裝軟件工具，其在企業(yè)內(nèi)部的落地實踐需要經(jīng)歷 復(fù)雜的轉(zhuǎn)型過程。我們認為DevOps的成功實踐需要企業(yè)工程解耦化、流程協(xié)同

2、化和管理顆?；母淖?， 要走過從資源整合到自助服務(wù)的五個步驟。在這個過程中，企業(yè)和團隊需要更多地關(guān)注管理方式和文化 適應(yīng)性，引入專業(yè)機構(gòu)的咨詢和培訓(xùn)服務(wù)能夠有效減少DevOps轉(zhuǎn)型過程中的摩擦成本。DevOps市場現(xiàn)狀：早在云計算誕生之前DevOps已然存在，長期以來DevOps實踐使用的軟件工具以 免費的開源軟件為主。盡管如此，一體化的DevOps平臺正在成為全球范圍內(nèi)的DevOps發(fā)展趨勢，國 內(nèi)企業(yè)通常采用一體化平臺+開源軟件的方式構(gòu)建自己的DevOps體系。2020年國內(nèi)DevOps服務(wù)的市 場規(guī)模達到27億元，未來5年的CAGR將超過25%，市場發(fā)展前景良好。DevOps應(yīng)用展望：D

3、evOps面對的企業(yè)文化上的敏態(tài)轉(zhuǎn)型以及其所使用的不斷優(yōu)化的開發(fā)/運維軟件都 決定了DevOps不會成為一種故步自封的工具，云原生更是為DevOps大展身手提供了廣闊的平臺。 DevOps將會在自動化、數(shù)據(jù)化、一體化和智能化方向上不斷自驅(qū)發(fā)展，DevOps與人工智能、無服務(wù) 器和安全工程的融合發(fā)展將會為DevOps注入新的活力和可能性。4初識DevOps：開發(fā)運維一體化不只是技術(shù)，不只是工具，不只是流程“DevOps”一詞是“Development開發(fā)”和“Operations運維” 兩個詞的組合，中文一般譯為“開發(fā)運維一體化”。雖 然在IT領(lǐng)域DevOps早已得到了業(yè)界的普遍認可并被投入各個

4、領(lǐng)域的廣泛應(yīng)用，但目前行業(yè)內(nèi)對DevOps還沒有統(tǒng)一明確的 定義。參考全球頭部IT公司對DevOps的理解，我們發(fā)現(xiàn)DevOps不是單一的技術(shù)或者工具，甚至不只是一個流程，它可以 被理解為一系列可以高速、高質(zhì)量進行軟件開發(fā)的工具鏈，這種模式不僅提高了軟件開發(fā)的效率和最終產(chǎn)品的表現(xiàn)，更是 現(xiàn)代IT企業(yè)協(xié)作及共享文化的體現(xiàn)和應(yīng)用。全球四家頭部IT企業(yè)對DevOps給出的定義能夠進行協(xié)調(diào)和協(xié)作， 以生產(chǎn)更好、更可靠的 產(chǎn)品。亞馬遜 “哲學、實務(wù)與工具” DevOps是集文化哲學、實務(wù)與工具于一身的 結(jié)合， 可提升組織快 速交付應(yīng)用程式和服 務(wù)的能力，能更快速 地開發(fā)和改進產(chǎn)品。微軟 “人員，流程和產(chǎn)

5、品” DevOps是人員，流程和產(chǎn)品的結(jié)合， 使以前孤 立的角色（開發(fā)、IT 運谷歌“組織和文化”DevOps是一項組織和文 化運動， 旨在加快軟件 交付速度， 提高服務(wù)可 靠性， 并在軟件利益相 關(guān)方之間建立共享所有 權(quán)。IBM“軟件交付的方法”DevOps是一種敏捷軟件 開發(fā)方法，開發(fā)和運營 團隊用于快速、質(zhì)量和營、質(zhì)量工程和安全）控制地構(gòu)建、測試、部署和監(jiān)視應(yīng)用程序。51.1 Who does it affect?誰與DevOps有關(guān)？6多個部門共同構(gòu)建軟件開發(fā)體系高效的軟件開發(fā)需要有效的部門間協(xié)作體系隨著軟件開發(fā)產(chǎn)業(yè)不斷規(guī)模化和規(guī)范化發(fā)展，軟件開發(fā)已非軟件工程師憑一人之力即可完成的工作

6、。在整個軟件開發(fā)運維 的生命周期中，需要產(chǎn)品經(jīng)理與客戶進行需求的溝通和對接，需要多個軟件工程師構(gòu)成的開發(fā)團隊共同編寫程序代碼，需 要測試團隊對代碼和軟件半成品進行檢驗，在通過最終的檢測以及客戶的審核之后還將面臨軟件部署上線以及使用期間的 運維。整個過程依賴于IT部門不同人員和團隊之間、甚至不同企業(yè)之間的通力合作。而隨著互聯(lián)網(wǎng)時代的到來，客戶需求 和外部環(huán)境的快速變化又對軟件開發(fā)運維的質(zhì)量和效率都提出了更高的要求。DevOps在這樣的背景下應(yīng)運而生，正是為 了給IT人員提供統(tǒng)一的工作環(huán)境和高效率的工作流程。軟件開發(fā)的工作體系由多個要求有效合作的職能板塊構(gòu)成代碼應(yīng)用軟件源代碼的編寫是軟件的軟件開發(fā)

7、的 基礎(chǔ)，也是研發(fā)人員最主要的工作之一交付在程序通過檢驗之后將移動到 類生產(chǎn)環(huán)境中進行運行試驗部署當交付的代碼通過驗證將部署 到實際的生產(chǎn)環(huán)境中項目管理項目經(jīng)理和IT部門領(lǐng)導(dǎo)負責項目的統(tǒng)籌 和項目成果的績效評估安全安全防護工作有可能是專門的團隊擔 任，或者由開發(fā)團隊一并負責測試測試人員和團隊將對開發(fā)團隊編寫的代碼 程序進行性能和安全方面的測試71.2 Why do I want it?企業(yè)為什么要引入DevOps？IT人才市場供不應(yīng)求來源：國家統(tǒng)計局，研究院根據(jù)公開資料研究及繪制。企業(yè)需尋求內(nèi)生途徑以加強IT部門運行效率隨著我國企業(yè)數(shù)字化轉(zhuǎn)型的不斷深入和互聯(lián)網(wǎng)經(jīng)濟的蓬勃發(fā)展，IT部門的職能由信

8、息化支持向業(yè)務(wù)賦能轉(zhuǎn)換，伴隨著信息 技術(shù)產(chǎn)生的社會價值和企業(yè)價值越發(fā)顯著，IT從業(yè)人員的人力成本也在不斷提高。根據(jù)國家統(tǒng)計局對我國2018年和2019年 城鎮(zhèn)非私營單位員工平均工資的統(tǒng)計，信息技術(shù)從業(yè)人員的工資連續(xù)兩年位列統(tǒng)計局劃分的19個大類行業(yè)之首，超過年均 16萬元，2019年增速為9.3%，也位于各行業(yè)中的較高水平。這一方面反映出IT產(chǎn)業(yè)的價值得到了市場的充分認可，同時 也折射出這一領(lǐng)域的勞動力市場、尤其是高素質(zhì)人才供不應(yīng)求的現(xiàn)狀。從用人單位的角度上看，在無法急速改變?nèi)瞬攀袌?現(xiàn)狀和IT人員素質(zhì)的前提下，唯有通過內(nèi)生途徑提高IT部門的運行效率和工作質(zhì)量，才能塑造企業(yè)的IT競爭優(yōu)勢。20

9、19年信息技術(shù)行業(yè)平均年工資位列我國首位并保持較高增速16.1413.3513.1410.8910.7710.779.779.719.449.119.3%8.2%1.2%7.6%9.2%5.7%7.3%11.0%9.7%11.80%信息技術(shù)科學技術(shù)金融電/熱/燃氣/衛(wèi)生和社會工文體娛樂教育交運/倉儲/郵公共管理采礦業(yè)水供應(yīng)作政2019年城鎮(zhèn)非私營單位員工年平均工資（萬元）同比增速（ % ）7開發(fā)/運維部門涇渭分明以保障安全穩(wěn)定為主看重系統(tǒng)穩(wěn)定不出錯依靠流程化/經(jīng)驗化的積累開發(fā)和運維部門在工作目標上面臨分歧，難以有效溝通在信息技術(shù)人才緊缺、人員素質(zhì)不能完全滿足企業(yè)業(yè)務(wù)需求的現(xiàn)狀下，企業(yè)的IT部門

10、還要面臨傳統(tǒng)IT系統(tǒng)內(nèi)開發(fā)和運維架 構(gòu)的固有缺陷所帶來的低效能，使得減少協(xié)作摩擦、提高工作效能的工具和方法更加重要。由于存在著開發(fā)部門求“新” 而運維部門求“穩(wěn)”的核心分歧，傳統(tǒng)的開發(fā)部門和運維部門在工作環(huán)境、工作職能和工作目標方面都有著顯著的差異， 在一些情景下甚至相反，導(dǎo)致在實踐中兩者不僅不能有效協(xié)作，甚至還引發(fā)了一系列矛盾，如果不能從工作流程和管理方 法上做出改變從而調(diào)和這樣的分歧，就難以培養(yǎng)起積極協(xié)作的文化氛圍，對IT部門效能提升將造成不利影響。開發(fā)部門和運維部門在工作內(nèi)容和需求上有諸多分歧主要在開發(fā)/測試環(huán)境中工作主要在生產(chǎn)環(huán)境中工作以滿足業(yè)務(wù)需求為首看重新功能的實現(xiàn)面臨個性化/定制

11、化需求總體來看研發(fā)人員處理的是 新的需求，在互聯(lián)網(wǎng)時代背 景下對高效率有著更高的需 求，對新方法、新工具也有 更高的接受度8運維人員處理的是日常的運 營和維護工作，保障系統(tǒng)的 安全、穩(wěn)定不出錯是其首要 職責，對新系統(tǒng)和工具有著 更多的擔憂盡管有著不同的職責和工作重心， 開發(fā)和運維人員都是為用戶創(chuàng)造 價值，需通力合作減少摩擦分歧10傳統(tǒng)軟件開發(fā)流程僵化瀑布流式開發(fā)不利于效率的提升，逐步向敏捷轉(zhuǎn)型與開發(fā)-運維兩分體系一同嵌入企業(yè)IT部門傳統(tǒng)思維的還有“瀑布流”式的軟件開發(fā)流程，在這一方法論體系下，軟件從需 求對接到產(chǎn)品上線要順序經(jīng)歷計劃-研發(fā)-測試-部署四個階段。盡管這一體系為早期的軟件開發(fā)產(chǎn)業(yè)提

12、供了有序的工作指導(dǎo)， 然而隨著軟件需求的更新頻率不斷提高，這一工作流程缺乏靈活度的問題開始顯現(xiàn)，其最主要的缺陷是工作進程之前耦合 度較高，不能夠?qū)崟r地對需求的變化做出反應(yīng)，目前僅適用于少數(shù)項目可計劃度高、需求變化頻率極低的軟件開發(fā)工作， 而對于電商、互聯(lián)網(wǎng)金融等敏態(tài)的需求場景則顯得笨重。傳統(tǒng)瀑布流式開發(fā)模式流程示意圖傳統(tǒng)瀑布流式的敏捷變化傾向計劃研發(fā)測試部署運維研發(fā)部門根據(jù)客戶需求編寫 代碼、進行軟件系統(tǒng)開發(fā)對代碼運行效果進行測試將已開發(fā)完成的軟件 部署到生產(chǎn)環(huán)境持續(xù)為客戶提供程序運行過 程中的支持和系統(tǒng)維護客戶經(jīng)理分析客戶需求，將客戶的需求反饋給IT開發(fā)部門設(shè)計開發(fā)測試部署設(shè)計部署設(shè)計開發(fā)測

13、試開發(fā)測試11IT部門管理透明度低、難度大IT業(yè)務(wù)的復(fù)雜性和專業(yè)性對領(lǐng)導(dǎo)層管理造成考驗除了IT部門和團隊內(nèi)部的交流協(xié)作模式在新經(jīng)濟時代需要作出改變，企業(yè)管理層對IT部門的把控和考核方法也亟需革新。 尤其是在以應(yīng)用軟件等信息技術(shù)已經(jīng)成為企業(yè)業(yè)務(wù)拓展“基礎(chǔ)設(shè)施”的大背景下，管理層有必要將IT部門的工作成效納入 其重點考察的對象當中。然而，IT工作的高度專業(yè)性往往在業(yè)務(wù)部門和管理層視野中間豎起一道技術(shù)壁壘，使得管理層無 法直觀地理解和分析IT部門的工作效能，因而也無法進一步為部門工作提出指導(dǎo)性和建設(shè)性的意見。在目前的軟件開發(fā)管 理實踐中，管理者不斷引入可量化的業(yè)績指標來增加IT工作對管理層的透明度，

14、然而這些考核在全面性、客觀性、有效性 方面仍有提升空間。企業(yè)亟需自動化、數(shù)量化、可視化的工具來提升IT部門的管理效率。企業(yè)IT項目/部門管理采取的部分指標及目前存在的全面性、客觀性及效率問題項目變更KPI主要考察的是一個IT項目在 需求和設(shè)計上發(fā)生變更的次 數(shù)，一般認為變更的次數(shù)越 少對項目成本管理越友好用戶滿意度KPI用戶滿意度比較難以可觀地度 量，一般而言系統(tǒng)故障次數(shù)、 用戶投訴和請求技術(shù)支持的次 數(shù)等可以用于衡量滿意度項目交付KPI主要是用于考核項目上線驗 收的準時性與，若項目的正 常上線和運行發(fā)生了延遲， 則會降低該指標的評價項目成本KPI用于考核項目的實際成本與 預(yù)算成本的關(guān)系，總體

15、原則 是在預(yù)算合理的基礎(chǔ)上盡量 減少實際發(fā)生的成本KPI是否全面？傳統(tǒng)的IT部門和項目管理指標受限 于數(shù)據(jù)的精細度和覆蓋度，無法提 供能夠全面反映項目執(zhí)行水平的可 量化的指標是否客觀？由于在一些評價上缺乏量化的工具 和自動化的數(shù)據(jù)收集/處理方法，一 些評價流程采用抽樣或項目主管自 行判斷，客觀程度有待提高是否值得？如果沒有自動化的指標采取和分析 工具，對IT部門和項目的成本管理 亦會成為部門成本和人員負擔，反 而降低企業(yè)效率121.3 What is it for real?DevOps究竟是什么，如何部署和運作？DevOps獨有的閉環(huán)流程概念緊密銜接的閉環(huán)流程DevOps賦能IT協(xié)作更加流暢

16、圖為DevOps方法獨有的開發(fā)-運維閉環(huán)流程，這一象征著循環(huán)與無限的符號包含著軟件生命周期中計劃-代碼編寫-構(gòu)建-測 試-發(fā)布-部署-運行-監(jiān)控的全流程，體現(xiàn)的是在DevOps理念與方法的支撐下，軟件開發(fā)與運維工作緊密銜接、開發(fā)與運維 團隊通力協(xié)作的理想狀態(tài)。21世紀以來不斷普及的敏捷開發(fā)帶來的最大變化是“解耦”了開發(fā)進程，使得這一過程更加靈 活和高效，DevOps則是在繼承敏捷開發(fā)工作方法的基礎(chǔ)上，進一步打破了開發(fā)和運維工作的界限，尤其是在容器技術(shù)的 幫助下，開發(fā)環(huán)境和生產(chǎn)環(huán)境的界限變得模糊，使得開發(fā)人員能夠執(zhí)行生產(chǎn)環(huán)境下的軟件運維工作，開發(fā)和運維部門的協(xié) 作由此變得更加簡單和高效。而由一系

17、列軟件開發(fā)和運維軟件工具構(gòu)成的工具鏈則是從技術(shù)上賦予了DevOps理念深入行 業(yè)實踐的動力，不僅改善了軟件開發(fā)和運維人員的工作體驗、加強了工作效能，也成為了管理層透視IT工作成效的豐富的 數(shù)據(jù)來源。在一些解讀當中，DevOps理念也包含軟件開發(fā)運維中的質(zhì)量控制QA環(huán)節(jié)。DevOps開發(fā)運維一體化閉環(huán)流程概念圖Code12BuildTestDeployOperateMoniterDevOps總覽DevOps的一般實踐流程項目管理人員用戶需求產(chǎn)品設(shè)計軟件A軟件B代碼編寫構(gòu)建反饋最終集成最終測試運維開發(fā)人員 測試人員測試人員項目管理人員工作成果評估敏捷開發(fā)單元測試持續(xù)對接用戶需求持續(xù)交付開發(fā)人員 運

18、維人員技術(shù)運維部署應(yīng)用設(shè)計動態(tài)的流水作業(yè)、迭代的開發(fā)進程、交互的協(xié)作模式從DevOps的流程實踐上看，總體來說其流程可以分為需求對接和應(yīng)用設(shè)計、敏捷開發(fā)和持續(xù)測試以及最終測試和上線運 維等三個階段，其核心是由開發(fā)人員和測試人員主導(dǎo)的敏捷開發(fā)和持續(xù)測試階段。借助Scrum或Kanban等工作流方法的指 引和一系列持續(xù)構(gòu)建、持續(xù)集成、持續(xù)測試以及持續(xù)發(fā)布工具，IT團隊能夠高效率地開發(fā)通過微服務(wù)架構(gòu)解耦的程序模塊， 并及時、持續(xù)地與用戶方面進行對接，對各個模塊的研發(fā)質(zhì)量和成果進行實時把控。在通過最終的集成和測試之后軟件得 以部署上線，此后開發(fā)人員能夠借助應(yīng)用容器化封裝帶來的統(tǒng)一環(huán)境之便，與運維人員一

19、起對軟件的運行質(zhì)量進行監(jiān)控、 為用戶提供支持服務(wù)，并繼續(xù)根據(jù)市場需求進行版本更迭的進一步開發(fā)工作。DevOps方法下的軟件開發(fā)運維一體化流水線工作流程13專人設(shè)計， 持續(xù)改進應(yīng) 用架構(gòu) 15.8%專人設(shè)計， 明確度量設(shè) 計質(zhì)量 11.8%專人設(shè)計和 模塊搭建 23.6%按經(jīng)驗進行 應(yīng)用拆解、 獨立開發(fā) 38.6%采用巨石 架構(gòu) 10.2%DevOps的應(yīng)用流程（1/4）應(yīng)用設(shè)計應(yīng)用程序單體架構(gòu)應(yīng)用程序微 服務(wù)架構(gòu)軟件架構(gòu)靈活解耦，筑基IT高效流程從軟件開發(fā)的實際工作流程上講，軟件應(yīng)用的架構(gòu)設(shè)計與開發(fā)/運維流程并不在同一層面。然而 在DevOps工作流程乃至整個云原生應(yīng)用體系中，以應(yīng)用容器化和微

20、服務(wù)架構(gòu)為基礎(chǔ)的軟件架 構(gòu)設(shè)計卻扮演著至關(guān)重要的角色。通過容器技術(shù)和微服務(wù)的結(jié)合，原本龐大的軟件程序得以被 拆解成為通過API連接的多個模塊，這樣的拆分不僅使得軟件開發(fā)和運維工程師的目標更加明 確、工作專注度更高，也為DevOps流程下軟件的拆分開發(fā)及協(xié)作集成提供一定的技術(shù)環(huán)境。從另一個角度上看，微服務(wù)和容器的結(jié)合已然成為眾多軟件架構(gòu)設(shè)計的默認選項，然而這一架構(gòu)的應(yīng)用也依賴于不同開發(fā) 者之間流暢的協(xié)作和IT團隊高效的管理，DevOps方法的引入也為微服務(wù)架構(gòu)充分發(fā)揮其長處提供了實踐環(huán)境。單體（巨石）式架構(gòu)與微服務(wù)架構(gòu)2019年我國企業(yè)應(yīng)用架構(gòu)設(shè)計狀況來源：中國信通院，研究院根據(jù)公開資料研究及繪

21、制。14所有團隊熟 練掌握，有 能力改善創(chuàng) 新一半以上團 隊處于較高 水平 15.7%部分團隊正 在使用優(yōu)化 28.1%少數(shù)團隊開 始使用 25.7%尚未使用16.6%DevOps的應(yīng)用流程（2/4）敏捷開發(fā)需求分析工作計劃開發(fā)工作回顧測試發(fā)布待開發(fā)開發(fā)中有問題已完成迭代流程&敏捷 開發(fā)Scrum& Kan- ban 方法代碼成果即時檢驗，工作進度可視管理敏捷開發(fā)的核心在于顛覆了傳統(tǒng)瀑布流模式下固化、耦合的開發(fā)流程，增加了開發(fā)流程的延展 性和靈活性，能夠更敏態(tài)地應(yīng)對實時變化的用戶需求，在互聯(lián)網(wǎng)市場環(huán)境變幻莫測的當下，這 賦予了開發(fā)團隊更好地面對競爭性市場的能力。借助各種團隊協(xié)作信息化工具，Sc

22、rum以及 Kanban等廣受IT企業(yè)歡迎的開發(fā)流構(gòu)建方法得到了電子化和自動化升級，開發(fā)和測試工作的連續(xù)性得到了進一步的提升，配合自動化的構(gòu)建、發(fā)布以及測試工具，原本由人工完成的一系列對于開發(fā)本身無效的流程工 作得到了簡化，而工作流程中自動生成的如發(fā)布次數(shù)、測試結(jié)構(gòu)等也直接成為的管理開發(fā)工作成效的可量化指標。企業(yè)敏捷開發(fā)迭代工作流程 & 看板管理方法2019年我國企業(yè)敏捷開發(fā)應(yīng)用狀況來源：中國信通院，研究院根據(jù)公開資料研究及繪制。15部署自服務(wù) 化，發(fā)布模 式持續(xù)優(yōu)化 19.0%部署自服務(wù) 化 15.5%部署全自動 化，測試/生 產(chǎn)環(huán)境實現(xiàn) 工具一致 20.7%部分部署自 動化 32.8%手工

23、完成部 署12.1%DevOps的應(yīng)用流程（3/4）持續(xù)交付客戶需求環(huán)境變化自動化部署/發(fā)布平臺開發(fā)成果便捷發(fā)布，客戶需求快速反應(yīng)較狹義的持續(xù)交付值得是將構(gòu)建和集成后的代碼不斷推送到審核、測試等環(huán)境的工作，而廣義 的持續(xù)交付還包含將測試通過的程序持續(xù)部署到生產(chǎn)環(huán)境的環(huán)節(jié)。持續(xù)交付不僅意味著提高初 次開發(fā)的整體效率以及發(fā)布顆粒度，也包括在初次部署上線后進行功能添加、缺陷修復(fù)等二次 升級過程中的工作流程。持續(xù)對用戶需求做出反饋和升級是持續(xù)交付的核心價值，自動化工具是實現(xiàn)持續(xù)交付的關(guān)鍵手段，企業(yè)的自動化水平很大程度上決定了固定時間內(nèi)集成、發(fā)布、測試的最大次數(shù)，反映IT團隊 敏捷應(yīng)對外部環(huán)境變化的能力

24、。DevOps持續(xù)部署和發(fā)布流程示意圖2019年我國企業(yè)自動化部署和發(fā)布能力狀況來源：中國信通院，研究院根據(jù)公開資料研究及繪制。16基礎(chǔ)系統(tǒng)級 監(jiān)控 28.0%覆蓋系統(tǒng)/應(yīng) 用/借口監(jiān) 控，具備數(shù) 據(jù)關(guān)聯(lián)分析 能力37.7%應(yīng)用場景告 警/可視化監(jiān) 控，常見故 障自愈 16.9%初步智能化 決策，數(shù)據(jù) 秒級上報12.7%4.8%2019年我國企業(yè)監(jiān)控管理能力狀況高度智能化決策DevOps的應(yīng)用流程（4/4）監(jiān)控運維告警指標自動分析，協(xié)同提升服務(wù)質(zhì)量軟件部署上線至生產(chǎn)環(huán)境后，服務(wù)提供商將繼續(xù)對該軟件的運行狀況進行監(jiān)控，并在出現(xiàn)故障 時為用戶提供運維支持服務(wù)。借助應(yīng)用容器化條件下統(tǒng)一的運行環(huán)境，開

25、發(fā)人員得以在更大程 度上進入運維側(cè)，通過自動化的監(jiān)控工具實時掌握系統(tǒng)和軟件的故障狀況。目前我國企業(yè)在這 一領(lǐng)域的發(fā)展仍比較有限，只有不足20%的企業(yè)具備智能化監(jiān)控和決策能力，在軟件可用性管 理方面，2019年我國企業(yè)應(yīng)用連續(xù)性管理能力狀況RTO99.995%以上，3分鐘解決問題4.6% RTO99.99%，5分鐘解決問題11.9%RTO99.95%，10分鐘解 決問題13.5%RTO99.9%，30分鐘恢復(fù)31.9%基礎(chǔ)應(yīng)急能 力，恢復(fù)時 間較長 38.1%來源：中國信通院，研究院根據(jù)公開資料研究及繪制。來源：中國信通院，研究院根據(jù)公開資料研究及繪制。17DevOps落地實施：理念認同顆?；?

26、/ 解耦 / 協(xié)同三重理念共同支撐DevOps實踐相較于單純的IT信息化工具，DevOps本身即是一種協(xié)同、合作的企業(yè)文化，為了落實DevOps實踐，企業(yè)在采用DevOps 相關(guān)的開發(fā)運維工具的基礎(chǔ)上，還要實現(xiàn)文化方面的理念認同。在工作結(jié)構(gòu)方面，IT工程需要在架構(gòu)和流程上都實現(xiàn)解耦； 在協(xié)同方法方面，IT團隊需要構(gòu)筑緊密協(xié)作、責任共擔的合作氛圍；在管理思想層面，IT管理層需要落實對部門工作顆粒 化、可視化、可量化的考核。美國DevOps平臺企業(yè)Quali的實踐研究表明，在嘗試DevOps方法的企業(yè)和人員中，認為企 業(yè)文化缺陷阻礙DevOps發(fā)展水平的占最大比重，顯示文化因素對企業(yè)提高開發(fā)運維一

27、體化水平的重要性。DevOps的實施需要企業(yè)對顆?；?、解耦、協(xié)同三影響企業(yè)DevOps實踐的阻礙因素TOP4 重概念的認可管理顆?；疍evOps的理念和方 法要求和推動企業(yè) 管理者加強對IT 工 作管理的顆粒度， 提高對工作流程和 成果的可見性和量 化管理能力工程解耦化工程解耦化要求IT 企業(yè)從軟件技術(shù)架 構(gòu)到實施流程上都 對開發(fā)和維護工作 進行系統(tǒng)性的切分， 使得團隊能夠?qū)Ｗ?于一項任務(wù)，同時 保持多項任務(wù)之間 的關(guān)聯(lián)和協(xié)作流程協(xié)同化建立在開發(fā)運維工 程和管理模式實現(xiàn) 解耦和分割的基礎(chǔ) 上， DevOps方法 需要協(xié)同合作、責 任共擔的工作氛圍 和價值認同來減少 合作摩擦、提升工 作效率14

28、% 企業(yè)文化來源：Quali，研究院根據(jù)公開資料研究及繪制。1813% 自動化12% 遺留系統(tǒng)11% 復(fù)雜程度20DevOps落地實施：階段路徑從資源整合到自動化逐步實現(xiàn)DevOps體系建設(shè)除了企業(yè)整體從文化需要面向DevOps的流程與方法進行調(diào)整與適應(yīng)，在實踐層面上也需要對IT部門的開發(fā)、運維流程進 行逐步的改造與升級。這一過程不是一蹴而就的，不同的企業(yè)也可以通過不同的路徑來打造最適合的自身DevOps方法。 一般而言，企業(yè)實現(xiàn)DevOps的落地需要經(jīng)歷五個階段，首先要實現(xiàn)企業(yè)內(nèi)部的資源整合，提高資產(chǎn)和任務(wù)的可見性；其 次是構(gòu)建統(tǒng)一、流暢的線上和線下工作環(huán)境及流程，接著要搭建能夠有效合作的團

29、隊體系，加強資源的共享；然后借助一 系列信息化的DevOps工具構(gòu)建企業(yè)的自動化開發(fā)運維流水線，并生成相應(yīng)的管理指標體系；當自動化水平發(fā)展到一定水 平且累計了充足的服務(wù)經(jīng)驗后，運維側(cè)即能以標準化的形式為用戶提供更高效便捷的服務(wù)。企業(yè)實現(xiàn)DevOps落地的五階段路徑資源整合團隊化自動化構(gòu)建資產(chǎn)池和任務(wù) 池構(gòu)建企業(yè)數(shù)據(jù)庫實現(xiàn)初步可視化流 程管理和任務(wù)管理標準化OaaS統(tǒng)一內(nèi)部操作環(huán)境 和軟件工具棧搭建簡單、合理的 審批和其他交互流 程，減少工作浪費實現(xiàn)任務(wù)流程內(nèi)生 化，盡可能減少外 包或與其他部門的 冗余交涉任務(wù)工具和流程達 到高復(fù)用度系統(tǒng)和軟件集成、 配置和部署實現(xiàn)自 動化實現(xiàn)全流程的可視 化管

30、理，工作結(jié)果 自動量化打包工作流實現(xiàn)高 度自動化和復(fù)用， 用戶自助調(diào)用運維， 實現(xiàn)Operationsas a Service運維及服務(wù)211.4 When do I know Im ready for it?何時才是企業(yè)運用DevOps的合適時機？適用于什么樣的團隊？單個團隊10-20人為佳，對外包和分散的敏感度較低IT團隊是DevOps理念和方法最終的實踐主體，盡管DevOps對團隊屬性并沒有固化的要求，然而在實踐中團隊的不同形式 對開展DevOps轉(zhuǎn)型可能會有顯著的影響，除了無形的團隊氛圍之外，一些客觀條件也可能會影響DevOps轉(zhuǎn)型的效果，本 報告著重討論IT團隊的規(guī)模，構(gòu)建方式以及地

31、理集中度對DevOps的影響。我們認為在這之中團隊的規(guī)模的影響相對顯著， 過大或者過小的團隊規(guī)模都會降低的DevOps的增效，在實踐中10-20人的（單個）軟件團隊能夠更好地發(fā)揮DevOps降本 增效的作用；而IT團隊是內(nèi)部團隊或是有外包團隊、團隊人員是否在地理位置上足夠集中兩方面的要素對DevOps實踐的 影響并不大，甚至可以認為DevOps的出現(xiàn)就是為了解決當前企業(yè)的IT團隊無法實現(xiàn)地理上的絕對集中以及完全內(nèi)化無需 外包從而帶來的摩擦問題。企業(yè)IT團隊特點對DevOps實踐的影響IT團隊構(gòu)建 自有/外包DevOps不僅是軟件工具 的安全， 還包含著企業(yè) 文化的改造和協(xié)作氛圍 的改善， 內(nèi)部

32、團隊更能 夠充分實踐DevOps的協(xié) 作理念和管理方法盡管如此，DevOps對含 有外包人員/業(yè)務(wù)的企業(yè) 也并非不能適用，它仍 然有助于軟件開發(fā)和運 維工作的順利進行， 并 且成為溝通內(nèi)部團隊和 外包團隊、提高工作效 率的重要工具02IT員工分布 集中/分散傳統(tǒng)意義上物理集中度 高的團隊能夠提高溝通 效率和效果，減少溝通 協(xié)作過程中的不必要摩 擦， 也能夠更有效地打 通研發(fā)和運維環(huán)節(jié)然而在信息化高度發(fā)展 的今天， 電子商務(wù)、在 線會議等應(yīng)用的普及使 得空間距離已不再是IT 協(xié)作的阻礙，可以認為 DevOps的出現(xiàn)也正是為 了進一步改善這一03IT團隊構(gòu)建 大/小團隊規(guī)模過大的團隊內(nèi)部結(jié) 構(gòu)復(fù)雜

33、， 工作流結(jié)構(gòu)不 清晰，如果以整體為單 位構(gòu)建DevOps框架會大 大增加系統(tǒng)的復(fù)雜性， 反而有違DevOps的初衷規(guī)模過小的團隊分工和 結(jié)構(gòu)簡單，引入DevOps 需要考慮成本效益問題從實踐經(jīng)驗上看，（ 單 個） 團隊規(guī)模在10-20人 能夠更充分地發(fā)揮DevOps的效用，對團隊 效率的增益最為顯著0121適用于什么樣的企業(yè)？業(yè)務(wù)系統(tǒng)頻繁更新的企業(yè)引入DevOps的價值更加顯著此處我們討論的是計劃將DevOps引入內(nèi)部IT團隊，并服務(wù)于母公司的軟件需求的企業(yè)，而非對外提供軟件開發(fā)和運維服 務(wù)的企業(yè)。由于互聯(lián)網(wǎng)經(jīng)濟和電子商務(wù)不斷向各行各業(yè)加速滲透，IT實力越來越成為影響企業(yè)運營水平的關(guān)鍵因素，

34、然而 并非所有的行業(yè)和企業(yè)（機構(gòu)）機構(gòu)都需要DevOps的加持，其中最核心的影響因素是該企業(yè)的業(yè)務(wù)是否需要頻繁發(fā)布新 的應(yīng)用來滿足用戶的需求，如果沒有此類的敏捷開發(fā)需求，或是目前正在運用的開發(fā)方法已經(jīng)能夠滿足企業(yè)的業(yè)務(wù)需求， 則開展DevOps的轉(zhuǎn)型耗費的資產(chǎn)和管理投入的性價比較低。此外，對于安全策略較為嚴格的行業(yè)和企業(yè)而言，雖然 DevOps能夠在一定程度上與安全審查流程融合，然而其敏態(tài)開發(fā)的效果將會有所下降。企業(yè)的核心業(yè)務(wù)及安全策略對開展DevOps實踐的影響目前的開發(fā)方法是否需要升級是否需要頻繁發(fā)布新應(yīng)用是否符合行業(yè)規(guī)范是否契合內(nèi)控流程安全策略業(yè)務(wù)需求若企業(yè)業(yè)務(wù)需求不滿 足以上條件，則應(yīng)

35、當慎重 考慮開展DevOps轉(zhuǎn)型實 踐的必要性和性價比問題若企業(yè)不滿足以上條 件，則需要審慎評估安全 策略對DevOps理念的落 實可能造成的阻礙22241.5 Where is it being used now?DevOps理念和工具在哪些行業(yè)有所應(yīng)用？傳統(tǒng)行業(yè)：數(shù)字化轉(zhuǎn)型捷徑DevOps助力傳統(tǒng)行業(yè)穩(wěn)步走上云原生數(shù)字化之路軟件開發(fā)和運營并非傳統(tǒng)行業(yè)的主營業(yè)務(wù)，因而整體上缺乏相應(yīng)的人才和軟硬件基礎(chǔ)設(shè)施，正因如此這類企業(yè)和機構(gòu)的數(shù) 字化水平整體較低。在我國數(shù)字化轉(zhuǎn)型的大趨勢下，找到適合企業(yè)的高效數(shù)字化轉(zhuǎn)型道路將意味著在市場競爭中取得先機； 對于政府部門而言，將能夠更好地構(gòu)建數(shù)字政府和數(shù)字政府

36、服務(wù)體系，提高地區(qū)乃至全國的信息化基礎(chǔ)設(shè)施水平。在傳統(tǒng) 航而已中，金融和能源等行業(yè)由于資金充足、技術(shù)實力相對領(lǐng)先，且對于各類軟件和在線應(yīng)用的需求較高，在傳統(tǒng)行業(yè)中 走在數(shù)字化升級的前列，也是率先引入DevOps方法和工具的行業(yè)。而新零售、智能制造等近年來逐步興起的互聯(lián)網(wǎng)+行業(yè) 也正在積極拓展互聯(lián)網(wǎng)能力構(gòu)建渠道以及市場優(yōu)勢。我國部分傳統(tǒng)行業(yè)面臨的IT現(xiàn)狀和困境及引入DevOps方法的效能傳統(tǒng)行業(yè)政府機關(guān)金融機構(gòu)零售企業(yè)能源企業(yè)IT研發(fā)與運維是重要 的工作支持體系，并 正在逐漸向核心能力 轉(zhuǎn)化IT工作大量外包，缺 乏對軟件流程的自主 掌控，系統(tǒng)的服務(wù)質(zhì) 量和運維穩(wěn)定性難以 保障傳統(tǒng)IT部門管理困難

37、， 人員和技術(shù)成本高增， 卻無法應(yīng)對市場對互 聯(lián)網(wǎng)應(yīng)用日漸增長的 需求在學習和實踐中逐步提高IT 部門的業(yè)務(wù)水平和管理水平， 將軟件科技能力逐步內(nèi)化為 企業(yè)/部門的核心優(yōu)勢競爭力實現(xiàn)IT部門的降本增效，提 高軟件服務(wù)門類以及質(zhì)量表 現(xiàn)，打造差異化競爭力加速云上數(shù)字化流程、提高 云原生水平，縮小與頭部科 技企業(yè)在數(shù)字化和網(wǎng)絡(luò)運營 水平上的差距，提高服務(wù)水 平和市場競爭力DevOps24科技行業(yè)：軟件工程新紀元DevOps賦能科技行業(yè)邁入軟件工程高效階段相較于傳統(tǒng)行業(yè)以及公共事業(yè)機構(gòu)，包括軟件、電商和電信運營商在內(nèi)的信息科技行業(yè)一直以來是IT科技創(chuàng)新的領(lǐng)跑者， 軟件開發(fā)和運維架構(gòu)是支撐上述企業(yè)業(yè)務(wù)

38、運營的核心能力，但也因為其IT架構(gòu)復(fù)雜、團隊龐大，在管理和協(xié)同優(yōu)化上面臨 諸多困難。DevOps理念和工具的有助于科技類企業(yè)統(tǒng)一IT環(huán)境、提高團隊反映能力和研發(fā)質(zhì)量，是企業(yè)提高其市場競爭 力的核心助力。目前我國的頭部科技類企業(yè)的軟件部門均大都通過自研或外采的方式引入DevOps工具、踐行DevOps流程， 是DevOps的主要踐行者。我國部分科技類企業(yè)軟件工程面臨的困境及引入DevOps方法的效能科技類企業(yè)軟件解決方 案商SaaS廠商電商平臺電信運營商IT研發(fā)能力是科技企 業(yè)的核心競爭力業(yè)務(wù)需求來源多樣， 開發(fā)部門權(quán)責分化， 開發(fā)流程復(fù)雜，不能 及時應(yīng)對外部需求和 環(huán)境變化IT部門員工水平參差

39、 不齊，代碼和運維質(zhì) 量難以保障，部門管 理透明度低、難度大業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)流程 存在各種交互協(xié)同創(chuàng) 造價值的可能性，開 發(fā)程度還較低統(tǒng)一開發(fā)環(huán)境，為IT團隊構(gòu) 建規(guī)范的、協(xié)同合作的研發(fā) 體系，打通研發(fā)與運維部門 之間的工作流程，提高IT工 作自動化水平加速對不斷變化的網(wǎng)絡(luò)環(huán)境 和客戶需求的反應(yīng)，實現(xiàn)新 應(yīng)用快速研發(fā)、部署和上線， 提高服務(wù)質(zhì)量和業(yè)務(wù)拓展速 度，快速獲得市場認可構(gòu)建研發(fā)和運維效果指標體 系，更好地量化IT團隊的工 作成果，便捷管理層進一步 優(yōu)化管理決策DevOps25271.6 How does it help your company?DevOps給企業(yè)帶來了哪些改變？2858

40、.5%54.7%49.1%40.6%34.9%34.0%33.0%16.0%提高開發(fā)提高產(chǎn)品提高用戶提高團隊降低部門提高交付提高工作為部門管理運維效率質(zhì)量滿意度協(xié)作水平執(zhí)行成本準時度負載上限提供量化依據(jù)DevOps為企業(yè)帶來的價值樣本：N=197；于2020年10月-2020年11月通過iUserSurvey調(diào)研獲得。工作效率及產(chǎn)品質(zhì)量得到提高，量化指標還有優(yōu)化空間調(diào)查結(jié)果顯示，DevOps實踐給企業(yè)帶來最顯著的收益主要包括提高了開發(fā)和運維工作的效率、提高了軟件產(chǎn)品的質(zhì)量以 及用戶的滿意度，此外DevOps也對團隊的協(xié)作水平、任務(wù)交付的準確度有所助益，并在一定程度上降低了IT部門的運行 成本、

41、提高了部門的工作負載能力。值得注意的是，相對較少的受訪者認為DevOps的引入為部門管理提供了量化依據(jù)。 我們認為這是由于目前國內(nèi)企業(yè)采用的DevOps工具在數(shù)據(jù)儀表盤的功能還不夠完善，盡管大部分的自動化工具都能提供 一些統(tǒng)計指標來反應(yīng)部門和員工的工作效率以及成果，然而這些指標可定制化的程度較低，比較局限于技術(shù)領(lǐng)域而非聚焦 管理視角，如果要為管理層提供更加清晰和多維度的管理透視，還需要加強指標構(gòu)建的靈活度和定制化能力。DevOps理念和方法給我國/IT部門企業(yè)帶來的收益442019.6 iResearch Inc.DevOps：不斷自驅(qū)與進步的IT文化自動化、數(shù)據(jù)化、一體化、智能化是未來Dev

42、Ops的發(fā)展方向盡管DevOps包含大量IT領(lǐng)域的技術(shù)和方法，然而更多是一種協(xié)作文化和企業(yè)管理的理念和思路，也正因如此，DevOps的 應(yīng)用框架不是一成不變的，將會隨著信息技術(shù)和軟件工具的發(fā)展而不斷革新、不斷適應(yīng)新的軟件開發(fā)環(huán)境和市場需求環(huán)境。 整體來看，未來DevOps應(yīng)用發(fā)展將呈現(xiàn)出自動化、數(shù)據(jù)化、一體化、智能化四大趨勢，分別對應(yīng)目前軟件開發(fā)和運維領(lǐng) 域人工參與較多、量化指標不夠清晰、開發(fā)運維鏈條有待完善和智能化程度尚待提高等主要問題，最終目標是最大限度減 少人工對無意義、重復(fù)工作的參與并提高軟件開發(fā)和運維工作的有效性。DevOps理念和方法的主要發(fā)展方向自動化盡管自動化的開發(fā)和運維 流程

43、在我國已經(jīng)過多年沉 淀，目前IT部門仍有大量 的任務(wù)是通過員工手動完 成， 加大了出錯的可能 DevOps在未來將通過與 RPA相結(jié)合，進一步提高 開發(fā)運維效率一體化形成一體化的DevOps 平 臺和工作流更加符合IT工 作者的提效需求。目前在 開發(fā)和運維軟件市場以及 相關(guān)領(lǐng)域的開源社區(qū)中已 經(jīng)存在了大量獲得市場認 可的工具，然而在過程銜 接和平臺適配方面還有很 大提升空間數(shù)據(jù)化隨著DevOps工具的自動 化升級，企業(yè)將能夠從IT 開發(fā)和運維過程中收集到 更多一線數(shù)據(jù)，通過整理 和分析生成指導(dǎo)未來IT工 作的有效信息，形成開發(fā)-數(shù)據(jù)-開發(fā)效能提升的工 作閉環(huán)智能化目前人工智能在諸多領(lǐng)域 的應(yīng)用

44、都體現(xiàn)出顯著的人 工替代效能，即利用機器 替代重復(fù)性的工作，這于 DevOps在軟件工程領(lǐng)域 的目標高度一致。人工智 能在DevOps領(lǐng)域的運營 將進一步提升軟件工程師 的工作效率和體驗Serverless + DevOps基礎(chǔ)設(shè)施運維業(yè)務(wù)流程運維傳統(tǒng)運維工作組成DevOps傳統(tǒng)運維工作中負 責保障軟件運行過 程中出現(xiàn)的問題的 部分將越來越轉(zhuǎn)移 到DevOps 方法下 的統(tǒng)一流程中Serverless傳統(tǒng)運維工作中負 責對底層服務(wù)器和 其他基礎(chǔ)設(shè)施進行 維護的部分將被轉(zhuǎn) 移到無服務(wù)器服務(wù) 中，由服務(wù)提供商 進行統(tǒng)一管理以底層資源的智能托管整合DevOps的運維工作無服務(wù)器架構(gòu)是目前仍處于技術(shù)探索和市場培養(yǎng)