DevOps 不僅僅是打通開發和運維之間的部門強，我們認為廣義DevOps是提供從業務、研發、營運三者之間的一個完整的閉環管理，更高效便捷的實作産品的靈活釋出與管理。DevOps 建構整個IT傳遞的生産線，提升IT的工程化能力，實作工程效率的提升。
1、IT精益營運與DevOps
随着企業的數字化轉型問題，要求IT從對内服務向内外兼修服務方式轉變。傳統應用的特點是：服務内部使用者；需求相對明确、功能全、覆寫廣、大內建、适合穩定發展階段；難以快速變化、維護成本高，快速變革的新業務态無法支援。
新興網際網路應用的特點是：服務外部客戶與合作夥伴；需求變動快、功能簡單、獨立和分散、分布式進化；應用規模變化大、大範圍廣泛的測試、易失敗、對業務彈性、快速釋出要求高。
普元實踐了大量企業數字化轉型的客戶，包括紅領、藍月亮等企業。從IT僅為内部客戶服務到逐漸轉向 2C。轉變的結果導緻IT傳遞的壓力變大。在傳統企業 IT人員又少的情況下（網際網路企業有大量的人員保障），怎樣快速地把我們的 IT傳遞出來，這是 DevOps 要解決的一個重要出發點。讓整個IT部門從傳統的支撐部門慢慢的變成業務創新部門，需要将IT的精益營運與 DevOps 無縫進行整合。
舉個例子來講，在飛機晚點的商業時刻，需要服務商幫助客戶做酒店變更，客戶的會議日程也要做出變更，所有這些事情都要求IT是自響應的，不需要像傳統的方式還需客戶進行自我服務。這種創新業務對IT的傳遞要求變得異常苛刻。當然在IT建設的過程中有很多協作的問題、大量的技術債務、新的技術架構的沖擊（微服務、容器等）。導緻業務應用變得非常複雜，傳遞困難，在這種情況下，DevOps平台或者說理念就逐漸的會普及開來，以支撐業務的靈活、企業大規模靈活。
2、對DevOps的認知
提到 DevOps，可能每個人心裡都有很多的圖。有各種基于技術、流程、文化次元的，還有類似元素周期表的。
我想說的是，在做 DevOps 的時候，到底應該解決什麼問題？其實這是我們必須要面對和回答的，隻有回答了業務上帶來的價值，才能讓 DevOps更好的落地。在傳統企業裡面，我們投入錢做IT建設的時候，它要的是投資回報率，也就是說我投了1塊錢在IT上，究竟給企業能帶來多大的業務價值。結合我們實施的一個客戶案例我們分詳細 DevOps 實際帶來的業務價值是什麼？
确定了一個很明确的業務目标： DevOps 平台建設完成後，要求IT效率提升 50%，具體拆解下來包括幾個次元：
1.測試環境和生産環境完全做到自動化部署；
2.業務流量有峰值或者浪湧的情況下，要能支援20倍的應用伸縮；
3.産品研發過程、項目管理過程完全能夠做到數字化，對整個IT團隊做數字化的考量；
基于具體業務目标而非技術目标，可以非常容易地在企業内部推廣DevOps的建設。
企業 DevOps 思維 VS 網際網路思維
網際網路裡面強調的一個字就是快（快到沒有任何底線），要求你的業務快速上線，周上線、天上線，甚至一天多次上線；而對于企業來講不能完全照搬網際網路思維的快；在企業裡面他們考慮的第一個是風險、品質。
傳統企業和網際網路還有一點不一樣的地方，在金融或者保險的行業它是有監管要求的，不是說要把所有東西都做自動化，那是不可能的。在企業裡面更多的要把應用的快速傳遞和品質保證找到一個平衡點。
DevOps 的本質是什麼？
我們認為 DevOps 就是給IT的生産、研發、運維做了一條傳遞線。本質上是提升整個IT的工程效率，解決軟體生産的工程化問題。
DevOps 把生産、研發、運維和雲平台（各種資源，IaaS、CaaS、實體機等）這樣一個大的流程無縫打通。DevOps 建設的重點也是圍繞這樣一個大的流程做一個全鍊路的打通，固化企業各種流程和最佳實踐。
上午分享的專家也講到，未來的運維要從傳統的運維走向面向應用的運維。其實 DevOps 也是一樣的，DevOps 一定要站在一個應用的視角去做管理和把控。站在一個應用的視角，我們要做什麼？
這個地方我給大家介紹普元 DevOps 平台對産品全生命周期的拆解：
主要包括産品（策劃、研發、營運、推出）、項目（立項、執行、完工），而靈活、持續內建、持續部署、持續傳遞都是 DevOps 的一個局部的階段。
DevOps 在支援全生命周期的過程，要以産品的視角來看待，真正進行傳遞的時候，也要以産品為次元進行組織的設立（網際網路公司通常如此）。但在企業裡面，産品思維還沒那麼強，仍然按照項目的方式來實施。
是以在企業實施 DevOps 建設中，要從産品、項目兩個次元來進行考量與拆解，關注每個階段管理的工件關鍵流程、關鍵度兩點。普元自身在進行 DevOps 建設過程中采用了 OPDM 的方法論進行每個環節的拆分，進而梳理出 DevOps 在每個關鍵環節的支撐能力。
DevOps核心觀點一：DevOps平台需覆寫産品、項目的全周期
接下來我會給大家以一個 OPDM 的模型對每個環節做拆分：
第一個O是管理對象，也就是在 DevOps 每一個生命周期環節裡面，首先要看我們的管理對象是誰；
第二個P是要知道在這個環境裡面，誰要在 DevOps 上使用，服務的角色是誰；
第三個是D，有了這樣的管理者和參與對象之後，要知道我這個平台關鍵的更新點是哪些，我要支撐哪些流程，有哪些最好的實踐能夠在這個平台上落地；
最後一個是M，也就是度量，這是衡量在 DevOps 平台上落地能力最好的度量工具。
首先從産品策劃這個角度來看，主要是産品經理使用；管理的工件是産品願景、MRD（市場需求）、BRD（業務需求），以及産品間的關聯關系。DevOps平台設計過程中需要關注不同産品級别的流程設計，以及提供整個企業次元的業務域的劃分與管理，包括業務子產品和産品線。
這裡面有一個最關鍵的點，你要針對企業未來生産的不同的産品，定義你的産品的運維過程、開發過程，以及它的支撐等級（每個級别的傳遞模式、運維模式都不同）。
立項周期、市場需求到業務需求的轉換率是組織最重要的度量點。
從産品研發的視角來看，研發階段主要是給産品經理使用；管理的工件是産品版本、 PRD、裡程碑、路線圖等。
DevOps平台設計過程中需要提供多版本的管理，以及類似版本号的最佳實踐能力；
PRD積壓、PRD變更、路線圖偏離度是重點評估的度量名額；
在這個階段我們最關心的是未來的 PRD 的積壓，因為 PRD 的積壓就說明了你的IT團隊生産能力是什麼樣的。一旦我的産品需求大量進入backlog，團隊知道部門的生産力跟不上，如果團隊要多接的話，就要犧牲産品的品質。
在産品管理中，小小的版本号其實内部藏着很大的學問，基于版本号可以快速了解産品的版本，釋出情況。甚至根據産品釋出後的版本号可以快速回溯到關聯代碼、關聯設計、關聯任務、關聯需求。如果能做到這些次元的關聯，大家對IT傳遞過程的管理就會達到一個較高的水準。
另外基于版本号，非常容易實作産品的版本看闆管理，随時了解産品不同版本的進展情況。
這是在普元 DevOps 平台上，我們的産品管理看闆。在看闆裡，你可以明确知道我的IT産品裡面有多少是正在研發的，有多少是在上線的，包括在不同環境裡的産品狀态。基于這個視角，我們認為 DevOps 要提供整個生産過程中最佳實踐的孵化和落地的工作。
evOps核心觀點二：DevOps平台更重要的是提供最佳實踐
接下來是營運階段，主要服務客服、營運團隊、産品經理等角色；管理工件主要包括事件、問題、配置、服務的SLA；
DevOps 平台設計過程中需要産品釋出的演練、緊急釋出、故障處理以及知識庫等積累；
客戶滿意度、MTTR、線上問題數是重點評估的度量名額；
在整個項目啟動和立項的時候，我們一旦把産品定義完以後，接下來就基于某個産品要做項目的開發。在項目的立項和啟動階段，最主要的是組建項目團隊包括權限，提供環境的快速開通。
DevOps 平台要提供整個團隊管理的能力，提供不同的角色在平台上進行協作，配置設定不同的權限。
DevOps平台需要提供關鍵的流程支撐，包括對過程的選擇（Scrum、傳統瀑布模式等），定義對應的傳遞流水線（每個不同的企業和項目對應的傳遞流水線都不同）。
項目傳遞流水線的示例：
個項目的傳遞流程一旦固定之後，整個團隊按照 DevOps 平台上對項目的傳遞流程進行協作，在流水線環節上定義具體的業務動作（內建、UAT、預發等），并可以設定自動執行還是人工接入；可以把每次傳遞的過程完全數字化、圖形化的方式展現出來。
傳遞流水線确定後，相當于我們以前推動這種項目制度規範的事情，可以通過在平台上按照流程的方式執行，把企業的最佳實踐能夠固化到DevOps平台上。
DevOps核心觀點三:DevOps平台，讓不同角色更好的在流水線上協作
再看項目需求階段，對産品經理、項目經理和架構師來說，平台要提供基于靈活的需求管理，包括 EPIC、Feature、 Story、Task；
DevOps 平台關鍵設計需要提供基于工作項的管理，包括需求、任務、缺陷的管理；
需求變更率、任務燃盡圖、積壓線是重點評估的度量名額；
通過 DevOps 平台需要做全流程的打通，打通了以後能夠給我們帶來的好處是什麼？可以從一個缺陷反向追溯隸屬的産品版本，對應的Task，對應的需求，這樣其實是做到很好的全鍊路的回溯。
項目架構階段主要提供給架構師、測試經理使用；管理的工件是系統關聯、接口定義、部署容器、元件。
DevOps平台設計過程中需要提供部署拓撲圖的設計，以及應用架構的設計（系統關聯關系、接口定義等）；
設計變更率、設計偏差是重點評估的度量名額；
在架構裡面，最主要的是要把我們的産品關聯組建拆分、以及要确定它的部署架構，包括有多少元件；有了這些設計後，DevOps 平台後續可以根據部署容器進行資源綁定，實作自動化部署；根據關聯關系确定依賴，進行部署器的依賴管理工作。
在部署設計中，提供了基于部署容器的概念，不同的部署容器可以編排依賴；在每個部署容器内部可以進行元件的編排。
容器其實是一個最小的部署設計單元，在部署容器内部可以定義元件，包括依賴的應用伺服器、JDK、甚至包括作業系統等。
這樣前期就可以定義系統的部署架構，而不是全部開發完成才定義部署的設計和安排；可以有效指導和限制後續的開發工作，使得品質提前進行管控。
DevOps核心觀點四:DevOps平台，管理前移，有效指導和限制後續工作
建構階段主要管理的是代碼庫、代碼的 Review、建構定義和建構執行。
DevOps 平台設計過程中需要提供最優的代碼庫使用方式，完成整個關鍵的建構定義、建構政策等工作；
代碼行、代碼送出頻率、建構次數/頻率、建構時長、建構成功率是重點評估的度量名額；
對于代碼開發模式，提供 TBD、GitHub、Git 多種不同的開發模式，讓團隊根據自己的實際情況選擇不同的協作模式。
比如 TBD，其實是基于主幹的開發，需要在主幹上随時可以打出最新的版本；當有新的版本需要釋出的時候，需要進行建立分支；在對釋出的版本進行維護的時候，需要将代碼送出到對應的分支、同時需要送出到主幹。
DevOps 平台就是要把這些最佳實踐固化進來，讓項目團隊成員去使用。
再舉個例子。我們都知道要做持續內建，做完持續內建之後，是不是能夠把最佳實踐展現出來。在代碼送出即觸發建構的情況下，如果編譯時間特别長，你怎麼解決？如果你每次代碼送出完以後，三分鐘可能開發人員還能忍受，5分鐘、10分鐘甚至更長的時候，就是實踐的浪費。
我們通過在 DevOps 平台上讓開發人員設定逾時時間，一旦超過這個時間，則認為建構失敗。DevOps平台會自動向架構師回報并送出一個缺陷，要麼是架構拆分的問題、要麼是建構存在過多的依賴，來實作架構的優化。
DevOps核心觀點五：對于已有系統， DevOps平台不僅僅是通過新的工具鍊實作快速傳遞，更是一種驅動優化的變革
測試階段主要管理的是代碼品質、測試用例、測試計劃、測試報告。
DevOps 平台設計過程中需要支援多環境的自動部署、多政策的部署，提供測試團隊進行快速的內建測試；
單元測試覆寫率、自動化測試比例、階段 Bug 比例、Bug 打回率、部署成功率是重點評估的度量名額；
在測試階段，需要盡可能的對測試用例進行自動化測試，能夠大幅提升測試回歸的效率，産品負責人可以快速的評估産品版本的品質。
預發/演練、上線階段主要管理的是部署環境、元件執行個體管理、部署計劃、傳遞物管理。
DevOps 平台設計過程中需要支援多政策的釋出，包括全新釋出、藍綠、灰階、金絲雀；應用可靠部署模式（叢集、多主、主備等）；
單元測試覆寫率、自動化測試比例、階段Bug比例、Bug打回率、部署成功率是重點評估的度量名額；
大家在講 DevOps 一定要做自動化，但是我們認為在做 DevOps 的時候，肯定不是全部的完全自動化沒有人工參與的。給大家舉個例子，我們做滾動更新的時候怎麼實作的？
再基于步長的應用伸縮過程中，第一個步長繩索後，需要測試新增節點的可用性，在OK的情況下才繼續做後續的伸縮并可以設定新的步長。
DevOps核心觀點六:DevOps平台，并不是自動化一切，而是在可控中有選擇的自動化
總結一下，我們對 DevOps的認知：
DevOps是一條IT生産線，核心價值在于提升工程效率；
覆寫産品、項目領域
展現出最佳實踐
加強協作
優化架構
可控範圍的自動化
3、企業實施 DevOps 的建設難點
接下來為大家從業務、方法論、技術三個次元分析實施DevOps的建設難點。
業務：
1、對于企業已有的工具，我們需要考慮怎麼內建，內建哪些；絕不是大而全的內建。如果專業系統足夠自動化、自助化，建議逐漸納入到 DevOps 平台，比如針對于底層的 IaaS 平台或者容器雲平台，我們就隻是進行接口調用，而并非功能的接管（專業的使用方式，還需要登入 IaaS 平台進行操作）；而對于 jenkins 這種敏感資源，更傾向于把整個 jenkins 封裝起來，不對外進行暴露。
2、關于 DevOps 的概念模型，平台的概念模型如圖所示，劃分為5大領域：産品域、組織機構與權限域，項目域、部署域、持續內建域，在實際DevOps平台落地過程中，可以從某個局部的域開始做傳遞。
3、在實施DevOps平台時，需要把企業的标準、規範固化和落地的平台，如果我們僅僅是把工具打通，帶來的業務價值是非常低的。
方法論：
1、從方法論來看，首先建議大家從工程效率或者工程度量的角度來衡量；
2、采用可疊代的MVP的方式傳遞産品，每次傳遞的都是完整可用的産品，友善快速對産品進行驗證和回報；
技術
采用微服務的架構進行平台建設，按照功能的次元進行微服務拆分，每個微服務内部嚴格定義 API、SPI；API 是 DevOps 平台對外提供的接口，可以友善內建；SPI 是對外內建的接口抽象，未來友善更換不同的內建工具；
4、DevOps 平台關鍵設計
DevOps 平台完整功能如下：
整個 DevOps 歸類了六大塊能力，分為靈活過程、持續傳遞、度量和優化三大能力，其中靈活過程包括産品、項目；傳遞流水線包括建構、部署、持續傳遞。
關鍵設計一：支援多種應用架構
DevOps 平台能夠支援多用應用架構，對上層的應用其實是透明的。
關鍵設計二：支援異構設施的多政策釋出
設計階段：将部署架構分為三層：部署裝配、部署容器、部署元件。設計（Design），是在裝配（Assembly）内對應用/系統的架構的描述；而應用/系統，是由含有多個元件（Component）的系統（Platform）組成的。
部署轉換：将部署裝配和資源（包括實體機、虛拟機、容器）進行綁定并生成部署計劃，按照對應的部署計劃進行執行，可以将應用推送到不同的環境中；支援灰階釋出、全量釋出、金絲雀、藍綠部署等；
元件營運：對産生的應用執行個體進行營運，支援啟動、停止、重新開機、狀态檢查、應用伸縮能力；
采用部署容器的設計，可以快速添加新的部署容器類型，下面給出了一個擴充支援移動應用的部署容器，可以快速的接入到 DevOps 平台中。
關鍵設計三：将企業最佳實踐固化到 DevOps 平台
需要總結梳理出固有的流程、規範和最佳實踐，将其固化到 DevOps 平台中，可以将項目管理（日報、周報、會議）、實時溝通工具、各種模闆、版本管理政策等最佳實踐落地，保障所有的團隊可以快速的掌握和使用這些技能。
5、如何邁出DevOps第一步
最後介紹一下我們是怎麼在企業裡面開始 DevOps 第一步的。
這裡我給大家建議了三個方向：
第一，從統一的組織架構、認證、SSO。企業裡面有這麼多IT系統，先做簡單的打通，否則後面做 DevOps 是非常困難的；
第二，從內建和自動化部署開始，這是最容易實作，也是最容易讓你的業務部門和老闆感覺到DevOps價值的入口；
第三，如果真正系統化地做 DevOps，我們需要把整個企業自身的研發過程和運維過程梳理出來，然後固化；
6、總結
最後總結一下，我們認為企業裡面做 DevOps，本質上就是做企業的IT生産線，最終是實作整個企業級的數字化生産線。目前大家都在講企業的數字化轉型，相信通過 DevOps 可以先讓IT部門進行數字化轉型，最終實作企業的大規模靈活。