今天要和大家闡述一個新的思路——建立面向應用的運維管理新思維,帶著這個思路去尋找運維新的解決方案,因此把面向應用管理抽象總結如下:
在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
http://www.bkjia.com/Linuxjc/1191934.html TechArticle