有標準化的自動化是平臺，無標準化的自動化是工具！

標準化在多個場合的交流中，始終是大家關注的焦點，無非就是What/Why/How之類的問題。當然脫離標準化，自動化是否可以執行？答案不能否定，但這樣的自動化成本和代價必須要更高。因為這樣，意味著每一次應用的接入都需要重新Review之前的自動化實現。其實我們不妨可以想象一下：

我們提倡標準化的核心就是基於打破職能和產品的邊界差異，實現規則的統一。我記得【持續交付：釋出可靠軟體的系統方法】中講到反模式，都是破壞Dev/Test/Prod環境之間的一致性（Parity）。因此基於一個標準化的自動化持續交付過程是實現環境一致性的必要條件。由此我也想到Docker所講的不可變基礎設施，其實核心的目標也是講如何基於不可變（Immutable）來確保環境一致性。殊途同歸！

過去我在不同的公司也實現過標準化，但始終沒有把他系統化和理論化的總結。藉助這次平臺落地的機會，我們對應用標準化進行系統化的整理，並付諸實踐。

優維EasyOps總結的應用標準化模型叫EasyXY模型，模型大體思路如下：

其中橫向為要標準化的實體，這個標準化的實體可以基於應用的某個OS內技術棧來進行梳理，比如說從作業系統到基礎環境到中介軟體再到上層的應用，這是標準化的Y軸。然後在基於實體要進行的標準化屬性進行識別，我們稱之為X軸。最終形成如下的二維象限：

基於如上的標準化屬性的劃分和識別，同時需要建立相應的標準化規則，否則這些屬性在使用過程中依然會混亂不堪。最終構建的規則如下：

這些規則非常重要，有些規則和Heroku的12factor是相對應的，比如說程式碼和配置、實體與資料隔離等規則等等。為什麼要建立這樣的規則？只有有效的隔離，方能做到環境的快速部署和切換。

其實從一個應用的程式碼包交付過程來說，無非就是其環境的交付、外部依賴的交付（執行時環境、公共庫、容器等等）以及應用程式包的交付。形如：

這樣的分解非常重要，實現應用交付過程的解耦，讓上次的自動化過程任意的組合，實現彈性應用交付。

對於每一個層次，我們又詳細的定義了其標準化的執行細則，就拿業務層的標準化來說，如下圖：

接下來在系統層面上要實現應用的整個應用的標準化交付管理，核心就是基於這些資源的標準化管理。

在這個應用為中心的介面中，實現了其資源的管理、關聯工具和流程的管理（動作管理）。另外我們還建議這個持續交付能力端不斷往持續整合（Dev）和持續測試（Test）方向去走，打造真正的持續交付鏈。在每次持續構建完成之後，自動觸發程式包（持續整合的後置任務）上傳到持續部署流程中來，如下圖：

基於標準化實現端到端的持續交付鏈之後，達到的收益非常明顯。這套標準化和自動化平臺落地之後，全環境部署效率提升224倍，應用部署升級效率提升120倍，關鍵是因為人為部署導致故障的產生大大降低，這個資料和2015年DevOps Report給出來的資料是類似的【效率提高200倍，故障恢復效率提升168倍】，原文如下：

High-performing IT organizations experience 60 times fewer failures and recover from failure 168 times faster than their lower-performing peers. They also deploy 30 times more frequently with 200 times shorter lead times。

本篇來源於優維EasyOps平臺在一個實際客戶落地實施後的經驗總結。

文/老王

文章出處：網際網路運維雜談