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

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

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

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

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

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

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

　　動作

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

　　狀態(tài)

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

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

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

　　但一定要注意CMDB的信息分成兩類，一類是實例信息，一類是連接信息，也稱為拓?fù)湫畔�。拓�(fù)湫畔⑿枰�結(jié)合我們平時的工作思路來建設(shè)和維護(hù)，比如說架構(gòu)視圖，是研發(fā)轉(zhuǎn)維的過程中，必須要提供的輸入，就是應(yīng)用架構(gòu)文檔。部署視圖，是指這個應(yīng)用上線部署在哪些機(jī)房，哪些node�；�礎(chǔ)架構(gòu)拓?fù)涫俏锢韔verlay，這個地方表達(dá)的是基礎(chǔ)設(shè)施層面的關(guān)系。業(yè)務(wù)流視圖分成應(yīng)用服務(wù)和端到端服務(wù)構(gòu)建的能力視圖，類似訪問流拓?fù)洹?/p>

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

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

　　階段

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

　　環(huán)境

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

　　動作

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

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

　　角色

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

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

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

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

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