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

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

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

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

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

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

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

　　動(dòng)作

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

　　狀態(tài)

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

　　CMDB建設(shè)的不成功，部分是系統(tǒng)的原因，但更多是方法論的問(wèn)題。我們總以為找到了很強(qiáng)的驅(qū)動(dòng)力來(lái)建設(shè)資源維護(hù)的流程和場(chǎng)景，其實(shí)這些都是自己的設(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資源生命周期管理建立起來(lái)之后，資源的廣度不斷拓寬自動(dòng)化的深度。

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

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

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

　　階段

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

　　環(huán)境

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

　　動(dòng)作

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

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

　　角色

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

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

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

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

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