運維需要思維的突破，從Ops走向DevOps，從項目走向產(chǎn)品，從資源走向應用~

很多問題一直在困擾、在思考，為什么CMDB大部分項目都是失敗的?為什么討論的更多的是運維自動化而不是IT自動化?為什么線上問題永遠是運維人的黑鍋?帶著這些問題我們來一探究竟。

今天要和大家闡述一個新的思路——建立面向應用的運維管理新思維，帶著這個思路去尋找運維新的解決方案，因此把面向應用管理抽象總結如下：

在ITIL時代，大家都知道一個概念，CMDB是IT服務系統(tǒng)的元數(shù)據(jù)中心，而現(xiàn)在應用更應該是CMDB的元數(shù)據(jù)。把運維的能力建立在面向應用的維度上，把面向應用的IT能力分成三部分：

CMDB即IT資源管理系統(tǒng)

支撐一個應用運行到底占用了哪些資源?應用占用的服務器是一種資源、占用的內(nèi)存是一種資源、占用的存儲是一種資源、占用的負載均衡是一種資源。但大家一定要注意，這個資源不是更多是一種后端服務出現(xiàn)，比如說IaaS服務或者是PaaS服務。

動作

應用的變更有很多種場景，按照角色來歸類，比如說應用交付、應用升級等場景，這些場景是面向Dev/Test/Ops的。還有一種應用在日常維護過程中的變更，面向純Ops場景的，比如說應用的遷移、應用的擴容。動作是作用于資源的，比如說應用升級是版本發(fā)生變化，應用擴容是讓應用的資源新增等等。過去的傳統(tǒng)式運維，總是聚焦碎片式的運維自動化能力理解上。

狀態(tài)

為了實現(xiàn)對應用的健康狀況或者質(zhì)量的度量，我們需要采集各類狀態(tài)數(shù)據(jù)，從而支撐各類場景的應用，比如說監(jiān)控故障發(fā)現(xiàn)的需求，故障恢復的需要，應用服務優(yōu)化的需要等等。

CMDB建設的不成功，部分是系統(tǒng)的原因，但更多是方法論的問題。我們總以為找到了很強的驅動力來建設資源維護的流程和場景，其實這些都是自己的設想。數(shù)據(jù)中心的基礎設施部門統(tǒng)攬CMDB的一切配置建設和管理，資源部門，根本不關心且沒法關心資源所關聯(lián)的上層應用是什么。

因此我主張把CMDB建設分層建設，業(yè)務層和資源層CMDB可以分開建設，但一定以應用的CMDB建設為主，倒推資源層的CMDB建設完善。以應用為中心的IT資源生命周期管理建立起來之后，資源的廣度不斷拓寬自動化的深度。

但一定要注意CMDB的信息分成兩類，一類是實例信息，一類是連接信息，也稱為拓撲信息。拓撲信息需要結合我們平時的工作思路來建設和維護，比如說架構視圖，是研發(fā)轉維的過程中，必須要提供的輸入，就是應用架構文檔。部署視圖，是指這個應用上線部署在哪些機房，哪些node?；A架構拓撲是物理overlay，這個地方表達的是基礎設施層面的關系。業(yè)務流視圖分成應用服務和端到端服務構建的能力視圖，類似訪問流拓撲。

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

可以把一個端到端的交付流水線，分成了四個標準化過程，縱向就分解了階段、環(huán)境、動作和角色等概念。

階段

是對交付階段的邏輯劃分，對于一個企業(yè)的某個產(chǎn)品來說，建設的標準是單一交付流水線，而不是多交付流水線，單一交付流水線才能保證整個交付過程的一致性。一般分成研發(fā)、測試、預發(fā)布和生產(chǎn)運維階段。

環(huán)境

環(huán)境是以上四個階段的進一步細分，在每一個階段會存在多環(huán)境的問題，比如說測試階段，有UAT環(huán)境、SIT環(huán)境;在生產(chǎn)階段，有正式生產(chǎn)集群、有容災備份集群等等。

動作

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

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

角色

誰來執(zhí)行這些動作，不同的環(huán)境可以面向不同的角色，這是權限的控制。通常分成開發(fā)、測試和運維角色，但真正到企業(yè)內(nèi)，角色的劃分會細致的多;其次這個角色也是隨著管理模式變化而變化的，測試人員可能來做生產(chǎn)環(huán)境的部署。

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

再回到運維自動化，在面向應用的自動化場景上，依然可以通過服務編排的模式來實現(xiàn)。但是回到其他運維資源上，就逐漸失去和應用的關聯(lián)，從管理方便性的角度來說，更是如此了。舉個例子，比如說數(shù)據(jù)庫的維護，大家肯定都是喜歡對數(shù)據(jù)庫的實例進行維護和變更，而不是再加一個應用的維度。在面向Iaas和PaaS能力的自動化上，可以面向資源進行動作服務編排，從而實現(xiàn)運維的自動化。

狀態(tài)其實是面向應用的一種度量手段，度量越貼近應用，越貼近服務，度量的有效性就越強。監(jiān)控手段是度量的一種，大家很多時候把監(jiān)控的告警能力、發(fā)現(xiàn)問題作為核心手段。但從這個維度出發(fā)，告警泛濫成為必然，大家不斷的去看提升告警的準確性，做告警收斂和告警關聯(lián)。我們的做法是告警可視化分層面板，在時間這個維度上，把告警統(tǒng)一展示，面向應用層的告警權重增大，底層的告警權重變小，衡量應用的健康狀況。其次在統(tǒng)一的看板上，人的思維會發(fā)生變化，底層的告警能力會不斷形成決策參考數(shù)據(jù)，而非當成直接的問題，甚至可以告警一致。這都是因為以應用為中心，數(shù)據(jù)有了關聯(lián)所致。

面向應用的運維管理新思維，是切實有效的，給過去的很多未解問題提供了解決方案，這也是我過去不斷強調(diào)要“建立以應用運維+運維研發(fā)為核心的組織體系”的原因。應用的是貼近業(yè)務的，因此應用是驅動力***的。