1.3　DevOps的現狀和發展趨勢

1.3.1　DevOps的現狀

DevOps經過了10多年的發展，很多企業或組織都在實踐DevOps。根據Gartner發布的2022年Agile（敏捷）和DevOps成熟度曲線（如圖1-2所示）顯示，DevOps的實踐處于多點開花階段（工具鏈、持續交付、DevSecOps等）。這充分說明DevOps已經經過了理論階段，向著實踐的深水區走去。

根據中國信通院（中國信息通信研究院的簡稱，下同）發布的《中國DevOps現狀調查報告（2021）》DevOps進行了級別劃分。

?初始級：在組織局部范圍內開始嘗試DevOps活動，并取得初期效果。

?基礎級：在組織較大范圍內推行DevOps實踐，并獲得局部效率提升。

?全面級：在組織內全面推行DevOps實踐并貫穿軟件全生命周期，獲得整體效率提升。

?優秀級：在組織內全面落地DevOps并可按需交付用戶價值，達到整體效率最優化。

?卓越級：在組織內全面形成持續改進的文化，并不斷驅動DevOps在更大范圍內取得成功。

2021年，成熟度處于全面級的企業最多，為35.4％，具備工具化、自動化、規范化的特點，同比增長8.84％；而16.53％的企業的實踐成熟度處于優秀級，具備平臺化、服務化、可視化與度量驅動改進的特點；0.87％的企業處于卓越級，能夠實現DevOps的高度智能化、數據化和社會化的特點，如圖1-3所示。

這些年，DevOps逐漸沉淀出了持續集成/持續交付（部署）（CI/CD）這種被認為是落地實踐DevOps的核心手段。同樣，《中國DevOps現狀調查報告（2021）》顯示：持續集成是最受歡迎的工程實踐，與自動構建、單元測試、持續交付占據前四，其比例分別為85.16％、81.61％、81.53％和80.66％，如圖1-4所示。

下面簡單介紹CI/CD的概念，第3章將詳細介紹。

CI和CD是實踐DevOps的兩大核心，也是DevOps實踐中比較容易實現的。

CI（Continuous Integration，持續集成）：指開發人員將代碼變更頻繁地向主干分支集成的過程，目的是將代碼變更可能造成的系統破壞性降到最小，一旦有問題，也能夠快速地識別和隔離變更集，保證主干分支實時可用。當然，這種“小步快跑”的開發有一個前提，就是代碼的集成要經過一系列既定的檢測或者測試流程。

CD包括兩種：Continuous Delivery（持續交付）、Continuous Deployment（持續部署）。

持續交付是一組通用的軟件工程原則，允許通過使用自動化測試和持續集成頻繁的發布軟件新版本。持續交付可以認為是持續集成的延伸。

持續部署是指通過定義測試和驗證來將風險最小化，從而將變更自動部署到生產環境。

為了推動CI/CD發展，Linux基金會專門成立了持續交付基金會（Continuous Delivery Foundation，CDF）。CDF的目標是改善軟件的交付能力，讓軟件交付變得更快速、更安全。目前（截至本書編寫時，全書同），CDF托管有Cdevent、Jenkins、Jenkins-X、Ortelius、Screwdriver.cd、Shipwright、Spinnaker、Tekton共8個與持續交付相關的開源項目。

【小結】DevOps經過了10余年的發展，已經取得了不錯的成果，而且在實踐的過程中沉淀了以CI/CD為核心關鍵能力的實踐方法。很多企業或組織在實踐DevOps的時候，CI/CD往往成為第一入手點，而且圍繞CI/CD產生了大量的開源項目，這也促成了CDF的成立。當然，CI/CD并不是DevOps的全部，也不等于DevOps。DevOps還在繼續演進。

1.3.2　DevOps的發展趨勢

DevOps從未停下向前演進發展的腳步，從目前看，DevSecOps、Cloud Native（云原生）是兩個非常明顯的發展方向。

1.DevSecOps

DevSecOps可以認為是DevOps的外延或者擴展，目的是將安全融入DevOps，讓安全能力滲透到軟件開發生命周期的各階段，從而為軟件研發和交付提供全方位的安全保障能力。所以，DevSecOps可以定義為：DevSecOps描述了一個組織的文化和具體實踐，這些文化和實踐能夠打破開發、安全、運維部門之間的壁壘，使得開發、運維和安全能夠通過通力協作和敏捷開發來提高工作效率，實現軟件的更快速、更安全交付。

DevSecOps有以下三個特點。

（1）安全左移

“左”或“右”是針對軟件開發生命周期來說的。

在傳統的軟件開發模式下（典型如瀑布式開發，甚至DevOps出現的早期），安全介入的時間比較晚，一般是在軟件開發的測試階段，甚至更靠后，從軟件開發生命周期看，是“向右”的。當軟件交付的周期比較長（半年甚至一年以上）時，這種模式并不會有太多的問題，也是業界比較常用的模式，因為交付周期足夠長，安全介入即使較晚，也有足夠的時間來完成相關的工作。但隨著用戶需求的多樣化、敏捷化，軟件發布的頻率必須提高才能響應用戶日益增長的需求，所以軟件的敏捷開發逐漸盛行，月發布、周發布甚至天發布都是稀松平常的。在這種發布頻率下，還要保持軟件的安全性，就給軟件開發帶來了很大的挑戰。

為了應對這種挑戰就需要讓安全盡量早地介入，在編碼甚至計劃階段就介入，從軟件開發生命周期看，是“向左”的，這也是安全“左移”的由來，如圖1-5所示。

安全“左移”的背后有一個安全問題修復成本與軟件開發生命周期關系（如圖1-6所示），也是為什么要實現安全“左移”的最大原因。可以看出，如果在軟件開發生命周期早期（計劃，編碼階段）發現安全問題，修復的成本是非常低的，越往后（測試，甚至生產階段），修復的成本越高，而且這種成本是非線性增加的。

（2）持續自動化

要保證軟件安全，需要有多種安全防護手段來為軟件提供從計劃到上線，從靜態到動態的安全防護能力，諸如SCA、SAST、DAST、IAST、Pen Testing等。如果都采用手動測試，那么對于開發、安全和測試來說，都是極具挑戰的，不僅增加了工作量，還可能導致這些人員在重復的體力勞動中喪失工作的積極性和創造性。因此，應該盡量實現安全防護手段的自動化，并且將其嵌入CI/CD，做到持續的自動化。

這樣做有以下好處：

?減少研發、測試等人員的工作量，減少重復的體力勞動，讓他們把更多的精力放在業務創新和賦能上。

?持續自動化能夠針對每次代碼變更都做到全方位安全防護，讓每次代碼變更都以安全方式交付。

（3）人人為安全負責

雖然從定義看，DevSecOps只包含開發（Dev）、安全（Sec）、運維（Ops）三個團隊，但是現代軟件的開發僅僅靠這三個團隊是無法完成的，還需要其他團隊的協作，如市場、銷售、產品等。因此，任何與軟件交付的團隊或個人都應該為軟件的安全交付負責，每個人都可能成為安全的瓶頸點，最終導致軟件的不安全。這與給F1賽車換輪胎非常像（如圖1-7所示），每個人都有自己的工作職責，但是最終的目的是一致的：在最短的時間內換好輪胎，并且保證安全性，從而提高車手獲勝的可能性。

2.云原生（Cloud Native）

云原生（Cloud Native）是由Pivotal公司的Matt Stine在2013年提出的。Matt Stine在他的著作Migrating to Cloud-Native Application Architectures中定義了云原生的幾個特點：①符合十二要素之應用（12-factor applications）；②微服務（microservices）；③自服務敏捷基礎設施（self-service agile infra-structure）；④API協同（API-based collaboration）；⑤反脆弱（Anti-fragility）。2017年，他做了自服務敏捷基礎設施如下修改：①模塊化（modularity）；②可觀測性（observability）；③可部署性（deployability）；④可測試性（testability）；⑤可替換性（replaceability）；⑥可處理性（handleability）。

Pivotal公司官方也對云原生有一個定義：云原生是一種充分利用云計算交付模式來構建和運行應用程序的一種方式方法，通常具有4個特征，即DevOps、持續交付（部署）（Continuous Delivery）、微服務（Microservices）、容器（Containers），如圖1-8所示。

不過，目前業界引用最多的是云原生計算基金會（Cloud Native Computer Foundation，CNCF）的定義：云原生技術有利于各組織在公有云、私有云、混合云中構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

CNCF與CDF一樣，也是Linux基金會的一個子基金會，是2015年由Google、RedHat、IBM、華為、Docker、VMware等公司共同成立的，致力于推廣先進的容器技術。CNCF目前托管141個（18個已經畢業、37個正在孵化、83個處于沙箱，并且有越來越多的項目被捐贈到CNCF中）開源項目，涵蓋計算、存儲、網絡、數據庫、持續交付等領域。

下面講述的Kubernetes和GitOps這些年在云原生領域非常熱門。Kubernetes是云原生的基座，而GitOps是云原生應用實現持續交付的新范式。

（1）Kubernetes

Kubernetes是一個可移植的、可擴展的、開源的平臺，主要用于通過聲明式配置和自動化來管理容器化的工作負載和服務。Kubernetes的名字源自希臘語，意思是舵手或者飛行員。由于開頭字母“K”與結尾字母“s”之間有8個字母，因此通常簡稱為“K8s”。

Kubernetes是谷歌（Google）公司2014年的一個開源項目，前身是Borg系統，始于2003年，是在谷歌公司內部使用的一個容器管理系統。Borg管理著來自數千個不同應用程序的數十萬個作業，涉及許多集群，而每個集群擁有多達數萬臺計算機。2013年，另一個Omega系統在谷歌公司內部應用，可以看作是Borg的延伸，在大規模集群管理和性能方面優于Borg。但是Borg和Omega都是谷歌公司內部使用的系統，也就是所謂的閉源系統。2014年，谷歌公司以開源的形式推出了Kubernetes系統，同年6月7日在Github上完成了第一次提交；7月10日，Microsoft、IBM、Redhat、Docker加入了Kubernetes社區。2015年7月，Kubernetes發布了V1.0版本，到目前是V1.25版本。

Kubernetes集群主要的組件分為控制平面和節點（Node）（如圖1-9所示）。控制平面（Control Plane）用來管理整個集群（如調度、檢測和響應集群事件等）；節點用來運行Pod（Kubernetes集群最基本的調度單元，其中運行一個或者多個容器，而應用程序運行在容器中）。

控制平面的主要組件包括如下。

①API Server（api）：用來對外暴露API的組件，也是所有請求的唯一入口。

②etcd：具有一致性和高可用性的鍵值存儲組件，主要用來存儲Kubernetes集群中的所有數據。

③scheduler：針對新創建的Pod進行調度，為其選擇一個合適的節點來運行。

④controller manager（c-m）：用來運行控制器進程的組件。Kubernetes有多種控制器，如用來管理運行一次性任務的Job控制器，給每個新的命名空間創建默認賬號的Service Account控制器，以及為其創建API訪問令牌的Token控制器等。

⑤cloud controller manager（c-c-m）：內嵌的特定的云端控制器邏輯，用于將用戶集群與云供應商的API進行連接，并將與該云平臺交互的組件和只與用戶集群交付的組件進行隔離，只運行用戶指定的特定云廠商的控制器。

節點的組件包括如下。

①kubelet：運行在每個節點上的代理，用于保證Pod內容器的正常運行。

②kube-proxy（k-proxy）：運行在每個節點上的網絡代理，主要用于實現Kubernetes中服務概念的一部分。

③Container runtime：容器運行時（runtime），用于運行容器。Kubernetes支持多種容器運行時，諸如containerd、CRI-O和其他實現了Kubernetes CRI的容器運行時。

（2）GitOps

GitOps是一個比較新的概念（由Gartner的2021 Agile和DevOps成熟度曲線也可以看出，GitOps處于萌芽期），由Weaveworks公司在2017年提出，是一種針對云原生應用進行持續部署的方式。其本質是利用云原生不可變基礎設施和聲明式API的特征，將云原生應用的狀態描述文件存儲在Git系統上（GitHub/GitLab等），任何變更的發起都在Git系統上，一旦有任何變動，變動會自動部署到目標系統上（通常是Kubernetes集群），如圖1-10所示。

GitOps有如下三個特征。

①以Git為單一可信源。所有內容都存儲在Git系統上，包括應用程序的源代碼、配置文件等。常見的Git系統包括GitHub、GitLab、極狐GitLab等。

②一切皆代碼。應用程序的描述、部署、基礎設施（利用Infrastructure as Code，基礎設施即代碼）等都是通過代碼的方式來進行描述的，然后存儲到Git系統上。

③以聲明式系統為基座。聲明式系統（如Kubernetes）的好處是只需設定應用程序的期望狀態，而不需關心整個過程，系統會自動將期望狀態和實際狀態進行對比，如果實際狀態與期望狀態有偏差，就會自動進行校正，直到期望狀態和實際狀態保持一致，如圖1-11所示。

GitOps的落地和實踐請參閱第4章。

【小結】DevOps目前的發展趨勢是將安全融入DevOps，打造DevSecOps，同時由于云原生浪潮的推動，DevOps和云原生在互相推動著彼此的發展，目前逐漸被認可和實踐的就有GitOps。