1.4 運維自動化的多維解讀

1.4.1 基于應用變更場景的維度劃分

我們曾經探討過，所有運維的價值導向最終都是面向業務、面向用戶，所以自然而然就需要從業務的維度進行劃分。而運維是有很多種場景的，但從業務的角度來說，核心的業務場景一般就包括如下5種：業務上線、業務下線、業務擴容、業務縮容和應用升級。下面將以其中一種場景為例，將整個流程穿起來看看，以此識別流程的節點到底對接了哪些系統？針對其他的業務場景，我們也可以用同類的方法進行分析。首先預設業務的架構如圖1-2所示。

（1）業務上線。表示上線一個完整的應用。從無到有部署整個業務上線，具體的流程如圖1-3所示。

仔細看圖1-3中所示的流程，我們會發現該流程涉及多個系統，每個系統所完成的職能又都有不同，這里只是大概地描述了一下。但一旦將這個流程清晰地梳理出來，我們就能知道真正地將一個應用全部上線到底有多復雜了。但看完圖1-3又會覺得其實比較簡單了，因為從業務上線的流程來看，我們只需要一個上層的流程調度引擎再加上對應的執行器，執行器通過API和底層的各個系統對接即可。這也是為什么之前在框架圖（圖1-2）中，要求各個專業系統一定要向上提供API，并且要求這個API的風格必須是一致的。

最復雜的業務上線流程梳理完成之后，業務下線其實很簡單，它是上線過程的逆過程，上線負責裝，下線負責拆。

業務上線之后，隨著用戶活躍度的上升，業務的容量逐漸會出現不足的情況，此時就需要進行業務擴容。業務擴容其實很簡單，當某類節點出現不足的時候，就對它進行擴容。業務擴容所要做的變更，其實都是業務上線的子流程。比如說如果Web層容量不夠，那就申請機器，安裝組件、下發應用包，進行自動化測試。這個時候需要注意的是：在業務上線的過程中，我們把很多的配置信息都下放到CMDB中了，因此我們在選擇擴容的時候，就要從CMDB中把信息讀取出來，以指導變更。

應用升級，目前持續集成所講的自動化都集中在這塊。簡單來講，就是升級程序包、升級配置、執行額外的指令等，一般來說逃脫不了這幾種模式。讀者可能會問，如果正如你所說的這么簡單，那么是不是將SSH封裝成一個UI就可以了。當然不是，這個時候還需要你以對運維的理解，在底層進行一些標準化的工作，否則你提供的就只是一個工具，而完全沒有運維的思路，比如說程序運行屬主、運行路徑、監控的策略等。另外建設應用發布平臺的目的就是要讓測試和生產環境的運維變得更可控。

以上幾個運維場景的自動化是否要一次性全部做完呢？當然不是，它們也是有先后和主次之分的。對于以上的運維場景，我在當前所負責的游戲運維中做過統計，數據如圖1-4所示。

（2）持續部署的數量，一個月2000次左右。

（3）其他場景的分布情況。一個月上線一次、下線兩次、擴容一次左右。

有了這個數據，我們在建設一個自動化系統的時候，就能意識到應該先做什么后做什么。當然，不同的企業有不同的實際情況，還是應該找到核心痛點，而不是一上來就建設完整的業務變更系統，那樣不僅見效不快，且容易讓項目收益不大，從而遇到很大的阻力。