编程 Firefox nginx 微软 开源 php Python 程序员 google Windows wordpress java Android shell linux 云计算 apache Ubuntu centos mysql

運維前線:一線運維專家的運維方法、技巧與實踐1.4 運維自動化的多維解讀

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

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

 

圖1-2 業務架構示例圖

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

仔細看圖1-3中所示的流程,我們會發現該流程涉及多個系統,每個系統所完成的職能又都有不同,這裏只是大概地描述了一下。但一旦將這個流程清晰地梳理出來,我們就能知道真正地將一個應用全部上線到底有多復雜了。但看完圖1-3又會覺得其實比較簡單了,因為從業務上線的流程來看,我們只需要一個上層的流程調度引擎再加上對應的執行器,執行

 

圖1-3 業務上線流程

器通過API和底層的各個系統對接即可。這也是為什麽之前在框架圖(圖1-2)中,要求各個專業系統一定要向上提供API,並且要求這個API的風格必須是一致的。

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

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

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

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

 

圖1-4 持續部署的數量

(2)持續部署的數量,一個月2000次左右。

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

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

1.4.2 基於系統層次的維度劃分

首先來看下系統層次的維度劃分,如圖1-5所示。

 

圖1-5 基於系統層次的維度劃分

給出如圖1-5所示的分層體系圖,其實就是為了讓大家更好地識別系統的職責和範圍,下層幹上層的活,或者上層幹下層的活都是越界,越界將帶來耦合的問題。舉個例子,系統服務層由Puppet(或者Chef)配置管理,但網上的很多資料都說Puppet可以用來做發布,也就是說可以做應用服務層的事情。後來我看過幾家用Puppet來做應用服務層發布的公司,最後都走不下去,因為應用包的需求變化太大,只靠Puppet編寫factor的模式來適應所有的場景,基本上是不可能的,所以說Puppet適合的是系統服務層配置管理。以上所舉的例子就是一種越界!

1.4.3 基於與業務程序耦合緊密程度的維度劃分

基於與業務程序耦合緊密程度的維度劃分,這點非常重要,這個劃分其實是確定系統建設的Owner,從而避免讓運維團隊承擔過多的系統建設職能,否則將會導致運維能力提升緩慢。那麽應該如何判斷與業務程序耦合的緊密程度呢?我的準則非常簡單,線上程序直接調用的就是緊耦合,或者由研發主導的公共服務,類似於API/SDK類的後端服務,應該由測試來主導系統建設;有些服務與程序不是直接關聯的,或者是由運維牽頭建設的,則由運維來主導,例如LVS、DNS服務等。

有這樣一種情況,在很多應用程序中,DNS和LVS服務也存在於程序調用鏈中,怎麽辦?在我的方案中,絕對不允許內部服務走DNS和LVS。我們都知道DNS和LVS的服務對於服務異常的處理(DNS無狀態、LVS是七層能力弱),遠遠達不到線上服務的要求,所以要堅決拒絕。如果真的有人要使用DNS和LVS,那麽第一告訴他們業務的風險;第二,發生故障的時候,需要讓研發參與處理。另外這也是系統的邊界沒劃分清楚的問題,是讓運維組件去承擔業務上應該具備的容災容錯功能,這會令後面的運維系統建設增加很多不必要的功能。

1.4.4 面向服務的自動化能力劃分

運維最終是需要對外提供服務的,這些服務能力應該由很多底層的自動化平臺來承載,個人對其能力劃分如下,其實細分到每一層都將發現自動化無處不在,而服務化的能力其實是自動化平臺的核心能力,能力劃分具體如圖1-6所示。

 

圖1-6 自動化平臺

1.?運營能力層

運營能力可體現IT運營價值,把IT的運營價值和業務場景緊密聯系在一起,這些場景和之前所談的運營價值體系(質量、成本、效率和安全)是一致的。在運維發展的不同階段,IT系統的運營價值體現會有所不同,IT運營的核心方法是要有叠代式的思維。

對於很多企業來說,自動化提升效率是運維的第一個價值突破點;再往後,業務的高可用保證和成本控制,則是下一個價值方向;再之後,精細化運營的業務支撐則是更高的訴求,類似於質量要求(質量的概念非常寬泛)。越往後,越能凸顯數據的價值,而非自動化工具的價值。因此我個人覺得在某一個階段,自動化平臺突破之後,主要的瓶頸將不是效率,而是數據化IT運營的能力。該能力在依賴平臺的同時,更依賴於運維團隊的業務理解能力和經驗總結。數據化運營能力是精細化的運營能力,是面向產品的,從底層的基礎設施質量、到應用的訪問體驗、再到產品發布後的用戶滿意度,等等。

這一層的能力表現為一個具體的產品形式+運營方法,從而可以確保能夠很好地閉環起來。舉個例子來說:基於資源容量管理的成本優化能力,首先需要一個貼合面向應用的容量分析模型,現實中一般是通過應用所消耗的資源(CPU、內存、I/O、網絡等)進行分析運算;其次是需要通過IT運營分析產品來呈現應用的容量水平(當前、歷史等);基於可視化的數據呈現,建立相應的容量管理機制。這裏又分為如下三點:

(1)建立標準。低負載需要提升資源使用容量、高負載則需要擴容資源(降低資源使用容量)。

(2)明確責任人和職責。確定容量管理的負責人,可以按照應用的粒度進行劃分,同時還要明確這部分的管理要求,對於大規模服務來說,可以借用考核的工具來進行驅動。

(3)結果驅動。通過定時的結果可視化來驅動容量管理的持續優化。

2.?平臺能力層

一個完整的運維平臺應具有以下特點:

其能力是集成的,而非離散的——平臺需要提供很好的集成能力,讓系統得到收斂,避免將系統分割成單個的執行單元,用戶也會為此痛苦不堪。

其能力是場景化的,而非基於功能需求的——場景能夠串聯工具。

其能力是基於角色的,而非基於單一用戶的——運維的角色能夠清晰地定義場景需求,用戶的需求往往是片面而不真實的需求。

其能力是基於事務的,而非基於職能的——事務能夠跨越職能組,讓運維組織的自動化和數據能力流動起來。

平臺能力是指基於底層平臺構建起來的具有的運維自動化/數據化(監控+分析)/安全的能力,這層能力實現了底層能力的組合與封裝,屏蔽了底層各個專業子平臺的實現細節,是面向業務運維場景的,比如說應用交付、資源交付、業務交付、持續反饋等。

3.?通用能力層

通用能力層是基於基礎設施之上封裝的公共服務能力,這層架構的能力可分成兩個部分:一部分是面向業務技術架構的,另一部分是面向運維服務架構的。圖1-6中所列的服務只是其中的一部分,這個也是我經常和交流者強調的能力建設的核心,不能把這個問題留給下面的資源能力層,也不能交給上層的平臺能力層。

對於線上技術架構來說,通用能力層將會涉及名字服務、負載均衡服務、分布式緩存、消息隊列、分布式關系存儲等,運維需要對其技術實現的工作人員要求API直接調用的服務能力。

對於運維服務來說,通用能力層提供了資源服務、作業服務、部署服務、F5管理、GSLB等。這層的平臺能力我一直將其理解成是PaaS平臺的核心,有了它們其實就可以實現端到端的能力調度。

該層服務能力平臺可以很好地對上層平臺進行積木式的支撐,同時還可以對底層設施層能力做服務化能力交付,脫離了資源交付的範疇。

4.?基礎設施層

基礎設施層是資源交付層,對於一個運維系統來說,應該屏蔽底層基礎設施的交付能力,無論是IaaS,還是物理層基礎設施。尤其是對於一些IaaS雲平臺來說,更應該屏蔽IaaS底層實現的細節差異,通過API服務向上提供能力。國外早年就有了同類的產品,如RightScale,它很好地實現了多雲管理的能力。

延伸阅读

    评论