本文首先會和大家分享當前整個應用生命週期的演變歷程，然後講解雲端計算模式下 DevOps 建設包含的過程、流程規範和標準，最後講解雲原生時代到來會帶來哪些改變，以及標準化的建設會有哪些改變和突破。
應用的演變歷程
企業數字化轉型過程和雲的迭代發展是相互作用的。在 2007 年之前主要用物理機來作為我們當前應用的載體。而在 2007 年，KVM 誕生，它能讓底層作業系統和一些虛擬的網路裝置做一些虛擬化的輸出。2007 年 - 2010 年是虛擬化發展較好的週期，VMware 和 openstack 是當時的代表生態。到了 2013 年 Docker 開服，雲端計算迎來了蓬勃發展的週期。2014 年，企業的部分業務開始逐步遷移雲上。2017 年後到今天為止，在雲原生的模式下，開發人員或者整個 it 部門更聚焦在業務的發展上，所有我們不關心的部分可以全部由雲來管理。雲開發不必關心開發在哪裡，雲服務不關心呼叫到哪裡，而云資源方面也不用關心執行到了哪裡。這就是從基礎設施上雲到業務上雲，再到當前的全棧雲，這樣的一條全企業數字化轉型之路。
在物理機階段，使用的是單體架構，這樣的架構系統封閉、無法複用，且高度耦合，內部互動複雜。而在第二階段，採用了面向服務的 SOA 架構，這種架構通常需要 ESB 進行系統整合，進行應用模組解耦，需要統一部署。但是這種架構通常需要較大規模的團隊，且可能存在職責割裂。第三階段是當前使用的比較多的微服務架構，它能充分利用 DevOps，完全解耦能充分利用雲化資源自動彈性伸縮等特性，支援高可用，能升級、擴容但不中斷業務。
這張圖片能較好的展示應用的生命週期管理，以應用為中心，在應用之上是基礎資源管理層面，這個層面可以管理應用對應的資產、環境、資源、流水線、部署和監控，這是以基礎資源為核心思想下 DevOps 的建設方向。隨著越來越雲化和微服務化，我們關注的視角從基礎資源逐步轉成服務思想。
雲端計算模式下的 DevOps
在物理機時代，隨著業務的發展，可能會出現基礎設施增長，軟體複雜度提升，流量衝擊和更新頻率變高這些問題。基礎設施增長和軟體複雜程度提升會給運維帶來壓力，流量衝擊要求運維的測試要有多樣的變化，更高的更新頻率要求研發人員的快速反饋以及更靈活的需求變更。
在這樣的情況下，DevOps 建設迫在眉睫，企業需要提升應用交付的效率和質量，需要越來越多樣化的應用部署方式。DevOps 建設要首先要做的是敏捷的建設，因此需要更靈活的需求管理工具，在整個應用交付階段需要自動化構建和環境快速管理。然後在測試的階段，我們需要做自動化測試，才能在流程中管控好質量，另外還需要有一個統一的製品管理。從軟體開發到應用交付之間，需要有一套統一的製品庫將所有的製品進行統一納管，基於統一的製品可以進行智慧化的驗收測試。在這整個階段，核心準則是版本控制一切，內建質量、自動化，過程度量。
這個圖片是端到端的 DevOps 能力圖譜，建設的重點在圖譜下方的持續交付工具鏈。我們需要採取統一的程式碼管理工具，幫助我們自動化的提升程式碼的質量。在安全方面，我們也會運用安全掃描工具整合到流程中，讓它進行自動編譯。另外，在持續部署階段，要做好資料庫的釋出，對不同版本的介面做好管理，並結合一些好的自動化的工具做自動化測試。這些功能點需要一個交付部署流水線串連起來。
我們可以看到，在端到端的能力中會有很多步驟，也需要非常多的工具去執行，如何將這些工具進行很好的串連呢？在企業生產過程中，核心目標有三項：效率、質量和成本，因此可以沿用製造業的流水線來幫助我們快速的生產軟體。流水線中我們需要關注 4 項指標：釋出頻率、變更時長、服務恢復時長和變更失敗率。
雲原生帶來的改變
雲原生是一個複雜的東西，它包含開發過程、應用依賴、編排管理、流程管理、資料分析以及非常多的元件。在雲端計算的模式下，我們可以做到快速交付應用、成果快速釋出，但是我們交付的產品是否能給業務帶來增長，滿足客戶的需要呢？這就涉及到如何將應用交付轉變為價值交付。通過可靠、可重複的流水線，快速進行軟體生產，提升應用效率和軟體交付效率，這就是應用交付。而價值交付是指能夠快速地響應市場變化，在客戶需求不確定的情況下，生產出客戶滿意的軟體。
如何實現價值交付？要基於可靠可重複的流水線，簡歷自動化的應用交付體系。將敏捷過程全面融入到 DevOps 體系中。架構全面微服務轉型，基礎設施雲化，讓開發專注於業務開發。將運營納入到 DevOps 範疇，實現數字化運營。
