本篇是上一篇【DevOps運維】構(gòu)建面向應用的運維管理新思維的延續(xù)。很早之前，我提到過，運維的本質(zhì)其實是在做交付，沒有做到面向用戶的交付，不是好運維，IT也不是一個好IT。如下圖：

• 可視化
• 拒絕碎片
• 服務與價值
• IT系統(tǒng)的ERP

從交付的目標來看，一定是朝著自動化的方向去走的，這個是從IT交付鏈的角度來分析，也就分析出IT自動化應該覆蓋的范圍了，公式如下：

IT自動化=DevOps自動化或者持續(xù)交付自動化+Ops自動化(Application Ops+Platform Ops + Infra Ops)。

為什么把Ops自動化獨立?全都是因為Ops的場景非常特殊，很多是運維獨立完成的，他覆蓋了更多的一些運維資源、變更能力，其中大部分能力是和研發(fā)、測試無關的，比如說應用的上線、擴容、遷移、切換;平臺運維對應paas;基礎設施對應IaaS等等。

一、DevOps自動化或者持續(xù)交付

DevOps自動化，可以認為是從應用的角度，構(gòu)建一個安全、快速且可持續(xù)的變更過程，這個地方包括版本發(fā)布、升級、回滾等等，當前業(yè)界***標準實踐是持續(xù)交付。持續(xù)交付可以說DevOps的核心工程實踐，也是精益企業(yè)的核心工程實踐。

構(gòu)建一個完整的持續(xù)交付自動化平臺，需要看到完整的能力框架。當前我在DevOps Master培訓班講授的持續(xù)交付課程里面，提出了以下【持續(xù)交付屋】模型：

• 目標是打造一個全自動化部署流水線，完整的整合構(gòu)建實踐、持續(xù)審查、測試、持續(xù)部署和反饋整個過程。
• 基于這個流水線自動化的能力目標，需要提供三大管理能力：平臺管理、能力管理、管理過程等等。
• 在平臺管理部分，需要提供標準化的持續(xù)交付平臺，對應企業(yè)的每個業(yè)務提供交付流水線。可視化平臺和監(jiān)控平臺分別是數(shù)據(jù)分析平臺和監(jiān)控平臺，從業(yè)務質(zhì)量優(yōu)化和問題驅(qū)動兩個層面來確保流水線的變更情況。
• 能力管理。提供了八大能力管理，這個能力管理的成熟度水平，決定部署流水線的水平。
• 管理過程。部署流水線打通公司部門墻，需要文化的支持、需要持續(xù)改善的機制、也需要有灰度實施的策略，從而取得突破。

打造持續(xù)交付流水線，我們過去的運維平臺建設思維都要發(fā)生變化。過去各自獨立建設的平臺現(xiàn)狀，都需要變化成以應用為中心的建設思路，詳見【DevOps運維】構(gòu)建面向應用的運維管理新思維。基于應用的整個生命周期的管理，才能打通整個交付過程。

很多運維在做自動化平臺的時候，非常獨立，忽略了早期的過程，運維應該走到前面階段，去看如何做好系統(tǒng)的標準對接點。Jenkins那邊提供提供的維度，應該自然的保留到運維的平臺中來。

其實一個很強的持續(xù)交付能力，是可以量化的，是需要把這個能力直接映射到一些IT管理維度上，同時提出明確的階梯管理要求。如下圖：

二、運維Ops自動化

Ops自動化的過程可以算作一個獨立的過程，比如說配置管理、IaaS、PaaS層的服務管理、應用層的運維自動化管理(遷移、容災切換)等等，簡單的應用持續(xù)部署不足以覆蓋運維自動化所有。之前談了很多，這個地方不講了。

如何在企業(yè)里面實施一個成功的交付?是否有標準可言?

這個在一些場合不斷的反復討論,因為涉及到DevOps實施的問題。其實在組織里實施一個系統(tǒng)工程，要么順序工程，要么并行工程。順序工程就是把最重要的先做了，單點突破;并行工程就是讓大家都動起來，一起參與，但這個依賴全局的組織動員能力、文化、執(zhí)行力等等。我建議的順序?qū)肼窂綀D：

***和大家一起探討一下交付的核心度量，一個好的交付應該關注哪些指標?

• (全局/核心)Cycletime/LeadTime。
• (全局/核心)交付頻率
• (全局/核心)服務恢復時長
• (全局/核心)變更失敗率

這個指標也是和DevOps 每年的規(guī)劃指標是一致的，這個指標是很好精確理解的，和行業(yè)是無關的。

運維必須要關注端到端的交付能力，端到端的自動化能力需要運維對開發(fā)、測試的能力足夠的了解，需要對運維平臺的整體規(guī)劃與設計，需要的是運維管理平臺的開放和集成能力。一定要放棄對運維自動化在工具層面上的認知，跳出之前的思維邊界。

【本文是51CTO專欄作者“王津銀”的原創(chuàng)稿件，轉(zhuǎn)載請注明出處】

戳這里，看該作者更多好文