大神教你如何構建面向應用的運維管理新思惟

今天要和你們闡述一個新的思路——創建面向應用的運維管理新思惟，帶着這個思路去尋找運維新的解決方案，所以把面向應用管理抽象總結以下：

在ITIL時代，你們都知道一個概念，CMDB是IT服務系統的元數據中心，而如今應用更應該是CMDB的元數據。把運維的能力創建在面向應用的維度上，把面向應用的IT能力分紅三部分：

CMDB即IT資源管理系統

支撐一個應用運行到底佔用了哪些資源?應用佔用的服務器是一種資源、佔用的內存是一種資源、佔用的存儲是一種資源、佔用的負載均衡是一種資源。但你們必定要注意，這個資源不是更可能是一種後端服務出現，好比說IaaS服務或者是PaaS服務。

動做

應用的變動有不少種場景，按照角色來歸類，好比說應用交付、應用升級等場景，這些場景是面向Dev/Test/Ops的。還有一種應用在平常維護過程當中的變動，面向純Ops場景的，好比說應用的遷移、應用的擴容。動做是做用於資源的，好比說應用升級是版本發生變化，應用擴容是讓應用的資源新增等等。過去的傳統式運維，老是聚焦碎片式的運維自動化能力理解上。

狀態

爲了實現對應用的健康情況或者質量的度量，咱們須要採集各種狀態數據，從而支撐各種場景的應用，好比說監控故障發現的需求，故障恢復的須要，應用服務優化的須要等等。

CMDB建設的不成功，部分是系統的緣由，但更可能是方法論的問題。咱們總覺得找到了很強的驅動力來建設資源維護的流程和場景，其實這些都是本身的設想。數據中心的基礎設施部門統攬CMDB的一切配置建設和管理，資源部門，根本不關心且無法關心資源所關聯的上層應用是什麼。

所以我主張把CMDB建設分層建設，業務層和資源層CMDB能夠分開建設，但必定以應用的CMDB建設爲主，倒推資源層的CMDB建設完善。以應用爲中心的IT資源生命週期管理創建起來以後，資源的廣度不斷拓寬自動化的深度。

但必定要注意CMDB的信息分紅兩類，一類是實例信息，一類是鏈接信息，也稱爲拓撲信息。拓撲信息須要結合咱們平時的工做思路來建設和維護，好比說架構視圖，是研發轉維的過程當中，必需要提供的輸入，就是應用架構文檔。部署視圖，是指這個應用上線部署在哪些機房，哪些node。基礎架構拓撲是物理overlay，這個地方表達的是基礎設施層面的關係。業務流視圖分紅應用服務和端到端服務構建的能力視圖，相似訪問流拓撲。

從應用的角度，資源的信息都可以很好的維護起來。此時就考慮如何支撐應用的動做了。這個場景起來以後，真正能解決CMDB數據維護動力和價值問題。面向應用的視角，提供完整的應用自動化和運維自動化能力。應用自動化打通Dev/Test/Staging/Prod等環境，構建面向用戶的端到端自動化能力。典型的場景就是交付流水線，示意圖以下：

能夠把一個端到端的交付流水線，分紅了四個標準化過程，縱向就分解了階段、環境、動做和角色等概念。

階段

是對交付階段的邏輯劃分，對於一個企業的某個產品來講，建設的標準是單一交付流水線，而不是多交付流水線，單一交付流水線才能保證整個交付過程的一致性。通常分紅研發、測試、預發佈和生產運維階段。

環境

環境是以上四個階段的進一步細分，在每個階段會存在多環境的問題，好比說測試階段，有UAT環境、SIT環境;在生產階段，有正式生產集羣、有容災備份集羣等等。

動做

交付的能力是動做來實現的，這個動做是一連串的能力編排。這個動做能夠分解成部署動做和附加動做。部署動做是完成一個環境部署的標準化過程，好比說初始化環境、安裝程序包等等，附加動做是針對特定環境要完成的一些動做，好比說針對用戶接受性測試，可能會運行自動化測試等等。部署動做要確保在各個環境之間的一致性，這是部署腳本的基本能力，避免動做行爲異化致使結果不一樣。

在動做層，還能夠面向封裝大量的自動化流程、工具能力等，這些能力都是知足一切應用場景的個性化。

角色

誰來執行這些動做，不一樣的環境能夠面向不一樣的角色，這是權限的控制。一般分紅開發、測試和運維角色，但真正到企業內，角色的劃分會細緻的多;其次這個角色也是隨着管理模式變化而變化的，測試人員可能來作生產環境的部署。

這個自動化能力就不是運維自動化，而是IT自動化。IT自動化的平臺能夠由運維來建設，確保可擴展、插件化的能力。擴展的能力，是能力能夠延伸到不一樣角色的須要，插件化是能夠集成不一樣角色過去的工具能力，從而實現一個面向DevOps的應用交付平臺。

再回到運維自動化，在面向應用的自動化場景上，依然能夠經過服務編排的模式來實現。可是回到其餘運維資源上，就逐漸失去和應用的關聯，從管理方便性的角度來講，更是如此了。舉個例子，好比說數據庫的維護，你們確定都是喜歡對數據庫的實例進行維護和變動，而不是再加一個應用的維度。在面向Iaas和PaaS能力的自動化上，能夠面向資源進行動做服務編排，從而實現運維的自動化。

狀態實際上是面向應用的一種度量手段，度量越貼近應用，越貼近服務，度量的有效性就越強。監控手段是度量的一種，你們不少時候把監控的告警能力、發現問題做爲核心手段。但從這個維度出發，告警氾濫成爲必然，你們不斷的去看提高告警的準確性，作告警收斂和告警關聯。咱們的作法是告警可視化分層面板，在時間這個維度上，把告警統一展現，面向應用層的告警權重增大，底層的告警權重變小，衡量應用的健康情況。其次在統一的看板上，人的思惟會發生變化，底層的告警能力會不斷造成決策參考數據，而非當成直接的問題，甚至能夠告警一致。這都是由於以應用爲中心，數據有了關聯所致。

面向應用的運維管理新思惟，是切實有效的，給過去的不少未解問題提供瞭解決方案，這也是我過去不斷強調要「創建以應用運維+運維研發爲核心的組織體系」的緣由。應用的是貼近業務的，所以應用是驅動力最強的。

 

原文來自：http://os.51cto.com/art/201611/522832.htm

本文地址：http://www.linuxprobe.com/operation-maintenance-management.html