簡介： DevOps 能力反映的是技術研發響應業務變化的能力。隨着組織規模的增加和業務復雜性增長，DevOps 能力會變得越來越重要。持續提升 DevOps 的能力成為技術研發的共同挑戰。
編者按：本文源自阿里雲雲效團隊出品的《阿里巴巴DevOps實踐指南》，前往：https://developer.aliyun.com/topic/devops，下載完整版電子書，了解阿里十年DevOps實踐經驗。
DevOps 能力反映的是技術研發響應業務變化的能力。隨着組織規模的增加和業務復雜性增長，DevOps 能力會變得越來越重要。持續提升 DevOps 的能力成為技術研發的共同挑戰。
為了給組織的 DevOps 能力提升指明方向，並規划清晰的路徑。我們定義了 DevOps 能力成熟度模型，它提供兩個價值：1）知道我們今天在哪里；2）如何規划提升路徑。
我們將 DevOps 的實施，分解為 4 大類，10 個能力，分別是：
基礎能力：包括系統的服務化水平和基礎設施水平兩塊，它是研發和交付的基礎。其中，服務化水平跟應用架構緊密關聯，最理想的情況是無服務化架構，比較低級的狀況是整個系統耦合在一起的巨石架構；基礎設施水平體現為研發對基礎設施所需要的關注度，需要的關注度越高，研發花在基礎設施上的成本越高，效率越低，而且穩定性反而難以保障。
交付能力：包括工具化水平、測試自動化水平和部署發布水平三大塊，它是工程能力水平的主要體現。其中，工具化水平指的是研發全流程中涉及到的各類工具的整體水平，包括單點能力（如項目協作工具、構建工具、依賴管理工具、環境管理工具等）和協同能力（如需求與發布的系統、缺陷與測試的打通等）；測試自動化水平指測試的反饋效率和自動化程度，測試自動化是工程能力的重要組成部分，也是提升部署發布能力的基礎；部署發布水平是指把制品上線到生產環境並提供服務的能力，包括發布的自動化程度、穩定性（如平滑的灰度發布）和適應性（即面向不同情況的處理能力及出現問題后的自愈能力）。好的交付應該是持續、快速、高質量和低風險的。
運維能力：包括系統的可觀測性、應用的運維水平和基礎設施的運維水平，是系統運行時彈性和韌性水平的體現。其中，可觀測性是運維能力中最重要的一環，主要體現在能否站在系統的角度看到全局的運行情況以及其中的問題，通常體現在監控水平和鏈路分析及問題定位能力上；應用運維是指對應用進行的運維操作，包括配置項的修改、調整應用運行時參數、對應用進行調整如擴縮容等；基礎設施運維是指對系統的基礎設施部分的運維操作，包括虛擬機、容器平台、基礎服務（如域名、配置中心等），這是整個系統的基礎部分。最好的運維就是自運維。
協同能力：包括業務和技術間的協同，以及開發與運維的協同能力，它是整體協同和業務響應能力的體現。其中，開發和運維協同是為了交付過程更加順暢和高效，以提高技術的響應速度，同時保障系統運行的彈性和韌性；技術和業務協同是為了讓從業務到技術的價值傳遞和交付更加精准、高效，反饋更加即時，以提高業務發展和創新的效率和效果。
成熟度模型
基於這 4 大類 10 個能力，我們給出了一個包含 5 個級別的成熟度模型，從 L0 到 L4 成熟度依次遞增。
| 分類 |
能力 |
L0 |
L1 |
L2 |
L3 |
L4 |
| 基礎能力 |
服務化水平 |
低（單體或剛開始進行服務化） |
中（基於特定框架下的業務開發） |
中（基於特定框架下的業務開發） |
高（僅關注業務開發，語言相關） |
高（僅關注業務開發，語言無關） |
| 基礎設施關注度 |
高（非雲原生基礎設施） |
高（非雲原生基礎設施） |
中（雲原生基礎設施） |
較低（主要serverless） |
低（完全serverless） |
|
| 交付能力 |
工具化水平 |
低（無DevOps工具鏈） |
中（部分、孤島式的工具） |
較高（持續交付工具鏈） |
較高（持續交付工具鏈） |
高（端到端devops工具鏈） |
| 測試自動化水平 |
低（無自動化，反饋時間長） |
低（無自動化，反饋時間長） |
中（部分自動化） |
較高（主要自動化） |
高（完全自動化） |
|
| 部署發布能力 |
低（手工發布） |
較低（自動化工具發布） |
中（自動化聲明式發布） |
較高（自動化聲明式發布，有干預的灰度能力） |
高（自動化聲明式發布，自動灰度能力） |
|
| 運維能力 |
可觀測性 |
低（只能觀測散點式的基礎資源） |
較低（散點式的基礎資源和服務接口可觀測） |
中（服務整體能力可觀測） |
高（全景業務能力和服務能力可觀測可追溯） |
高（全景業務能力和服務能力可觀測可追溯） |
| 應用運維能力 |
低（人工運維） |
較低（自動化工具運維） |
中（聲明式運維） |
中（聲明式運維） |
高（服務自運維） |
|
| 基礎設施運維能力 |
低（單點、人工運維） |
較低（單點、自動化工具運維） |
中（集群、自動化工具運維） |
中（集群、自動化工具運維） |
高（集群、自運維） |
|
| 協同能力 |
開發、運維協同能力 |
低（開發、運維分離 批量部署、獨立運維） |
較低（開發、運維協作部署，加大部署頻次） |
中（開發自主部署 開發協助應用運維） |
較高（開發團隊持續交付 開發、運維團隊融合） |
高（開發團隊持續交付、自運維） |
| 業務、技術協同能力 |
低（業務與技術相互獨立、拋接需求、很少同步） |
較低（業務與技術定期同步，批量開發、部署、發布） |
中（以業務需求為單位持續開發、部署、發布） |
中（以業務需求為單位持續開發、部署、發布） |
高（業務需求的快速響應和交付，業務需求的即時反饋、調整閉環） |
L0：手工批量交付、手工運維，這是零能力的 DevOps 階段，其服務能力完全取決於開發者個人，業務交付質量普遍不高，隨着業務的發展和團隊規模的變大會遇到各類問題，通常會首先尋求工具的幫助。
L1：手工為主、工具輔助的批量交付和運維，這個階段開始引入自動化工具來輔助進行運維、發布等工作，通常已經有了服務化的基礎，基礎設施已經部分上雲，並通過引入開源工具或自建搭建了一些完成特定訴求的工具，但這些工具往往還是孤島，沒有聯系起來，業務、開發、運維間采用定期同步的方式，需求的交付還是批量式的。
L2：基於業務需求的部分自動化的交付運維，這個階段能基於業務需求進行持續發布，已經采用了聲明式運維，通常已經使用雲原生的基礎設施，並且使用雲上的資源管理服務狀態，大部分工具鏈已經能串聯起來，實現一定程度的持續交付，服務開始具有中間件級別的抽象和治理能力，但一般還無法做到自運維，回滾等操作還需要依賴人來判斷和處理。
L3：基於業務需求的端到端自動化交付和有限制的自運維，這個階段的業務需求交付頻率和交付質量有了明顯提高，服務化水平已經相當高，針對特定的技術棧可以做到大部分情況下關注業務開發，主要服務以serverless 方式發布運行。發布過程可以做到自動化和聲明式，只在灰度處理上需要少量的干預，服務已經可以做到大部分情況下的自運維和自治理。
L4：業務需求的端到端持續交付和調整閉環、完全自運維，這個階段開發者只需關注業務開發，且業務需求能夠做到快速的交付和調整，服務化水平與技術棧解耦，做到完全 serverless 化。整個交付過程完全自動化，服務能夠完全自治理。這個階段是我們追求的目標。
本文為阿里雲原創內容，未經允許不得轉載。