編者按：本文源自阿裡雲雲效團隊出品的《阿裡巴巴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 化。整個傳遞過程完全自動化，服務能夠完全自治理。這個階段是我們追求的目标。
免費下載下傳《阿裡巴巴DevOps實踐指南》
阿裡巴巴合夥人和業界多位大佬力薦、何勉、陳鑫等17位阿裡資深技術專家聯袂出品、阿裡十年DevOps經驗沉澱總結、阿裡巴巴DevOps落地實踐一本通。
前往：
，下載下傳完整版電子書。
