構建面向交付的自動化運維新思維
本篇是上一篇【DevOps運維】構建面向應用的運維管理新思維的延續。很早之前，我提到過，運維的本質其實是在做交付，沒有做到面向用戶的交付，不是好運維，IT也不是一個好IT。如下圖：
- 可視化
- 拒絕碎片
- 服務與價值
- IT系統的ERP
從交付的目標來看，一定是朝著自動化的方向去走的，這個是從IT交付鏈的角度來分析，也就分析出IT自動化應該覆蓋的范圍了，公式如下：
IT自動化=DevOps自動化或者持續交付自動化+Ops自動化(Application Ops+Platform Ops + Infra Ops)。
為什么把Ops自動化獨立?全都是因為Ops的場景非常特殊，很多是運維獨立完成的，他覆蓋了更多的一些運維資源、變更能力，其中大部分能力是和研發、測試無關的，比如說應用的上線、擴容、遷移、切換;平臺運維對應paas;基礎設施對應IaaS等等。
一、DevOps自動化或者持續交付
DevOps自動化，可以認為是從應用的角度，構建一個安全、快速且可持續的變更過程，這個地方包括版本發布、升級、回滾等等，當前業界***標準實踐是持續交付。持續交付可以說DevOps的核心工程實踐，也是精益企業的核心工程實踐。
構建一個完整的持續交付自動化平臺，需要看到完整的能力框架。當前我在DevOps Master培訓班講授的持續交付課程里面，提出了以下【持續交付屋】模型：
- 目標是打造一個全自動化部署流水線，完整的整合構建實踐、持續審查、測試、持續部署和反饋整個過程。
- 基于這個流水線自動化的能力目標，需要提供三大管理能力：平臺管理、能力管理、管理過程等等。
- 在平臺管理部分，需要提供標準化的持續交付平臺，對應企業的每個業務提供交付流水線。可視化平臺和監控平臺分別是數據分析平臺和監控平臺，從業務質量優化和問題驅動兩個層面來確保流水線的變更情況。
- 能力管理。提供了八大能力管理，這個能力管理的成熟度水平，決定部署流水線的水平。
- 管理過程。部署流水線打通公司部門墻，需要文化的支持、需要持續改善的機制、也需要有灰度實施的策略，從而取得突破。
打造持續交付流水線，我們過去的運維平臺建設思維都要發生變化。過去各自獨立建設的平臺現狀，都需要變化成以應用為中心的建設思路，詳見【DevOps運維】構建面向應用的運維管理新思維。基于應用的整個生命周期的管理，才能打通整個交付過程。
很多運維在做自動化平臺的時候，非常獨立，忽略了早期的過程，運維應該走到前面階段，去看如何做好系統的標準對接點。Jenkins那邊提供提供的維度，應該自然的保留到運維的平臺中來。
其實一個很強的持續交付能力，是可以量化的，是需要把這個能力直接映射到一些IT管理維度上，同時提出明確的階梯管理要求。如下圖：
二、運維Ops自動化
Ops自動化的過程可以算作一個獨立的過程，比如說配置管理、IaaS、PaaS層的服務管理、應用層的運維自動化管理(遷移、容災切換)等等，簡單的應用持續部署不足以覆蓋運維自動化所有。之前談了很多，這個地方不講了。
如何在企業里面實施一個成功的交付?是否有標準可言?
這個在一些場合不斷的反復討論,因為涉及到DevOps實施的問題。其實在組織里實施一個系統工程，要么順序工程，要么并行工程。順序工程就是把最重要的先做了，單點突破;并行工程就是讓大家都動起來，一起參與，但這個依賴全局的組織動員能力、文化、執行力等等。我建議的順序導入路徑圖：
***和大家一起探討一下交付的核心度量，一個好的交付應該關注哪些指標?
- (全局/核心)Cycletime/LeadTime。
- (全局/核心)交付頻率
- (全局/核心)服務恢復時長
- (全局/核心)變更失敗率
這個指標也是和DevOps 每年的規劃指標是一致的，這個指標是很好精確理解的，和行業是無關的。
運維必須要關注端到端的交付能力，端到端的自動化能力需要運維對開發、測試的能力足夠的了解，需要對運維平臺的整體規劃與設計，需要的是運維管理平臺的開放和集成能力。一定要放棄對運維自動化在工具層面上的認知，跳出之前的思維邊界。
【本文是51CTO專欄作者“王津銀”的原創稿件，轉載請注明出處】
