構(gòu)建面向應(yī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能力分成三部分：
1. CMDB即IT資源管理系統(tǒng)
支撐一個應(yīng)用運行到底占用了哪些資源?應(yīng)用占用的服務(wù)器是一種資源、占用的內(nèi)存是一種資源、占用的存儲是一種資源、占用的負(fù)載均衡是一種資源。但大家一定要注意，這個資源不是更多是一種后端服務(wù)出現(xiàn)，比如說IaaS服務(wù)或者是PaaS服務(wù)。
2. 動作
應(yīng)用的變更有很多種場景，按照角色來歸類，比如說應(yīng)用交付、應(yīng)用升級等場景，這些場景是面向Dev/Test/Ops的。還有一種應(yīng)用在日常維護過程中的變更，面向純Ops場景的，比如說應(yīng)用的遷移、應(yīng)用的擴容。動作是作用于資源的，比如說應(yīng)用升級是版本發(fā)生變化，應(yīng)用擴容是讓應(yīng)用的資源新增等等。過去的傳統(tǒng)式運維，總是聚焦碎片式的運維自動化能力理解上。
3. 狀態(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)的原因，但更多是方法論的問題。我們總以為找到了很強的驅(qū)動力來建設(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資源生命周期管理建立起來之后，資源的廣度不斷拓寬自動化的深度。
但一定要注意CMDB的信息分成兩類，一類是實例信息，一類是連接信息，也稱為拓?fù)湫畔ⅰＭ負(fù)湫畔⑿枰Y(jié)合我們平時的工作思路來建設(shè)和維護，比如說架構(gòu)視圖，是研發(fā)轉(zhuǎn)維的過程中，必須要提供的輸入，就是應(yīng)用架構(gòu)文檔。部署視圖，是指這個應(yīng)用上線部署在哪些機房，哪些node。基礎(chǔ)架構(gòu)拓?fù)涫俏锢韔verlay，這個地方表達(dá)的是基礎(chǔ)設(shè)施層面的關(guān)系。業(yè)務(wù)流視圖分成應(yīng)用服務(wù)和端到端服務(wù)構(gòu)建的能力視圖，類似訪問流拓?fù)洹?/p>
從應(yīng)用的角度，資源的信息都能夠很好的維護起來。此時就考慮如何支撐應(yīng)用的動作了。這個場景起來之后，真正能解決CMDB數(shù)據(jù)維護動力和價值問題。面向應(yīng)用的視角，提供完整的應(yīng)用自動化和運維自動化能力。應(yīng)用自動化打通Dev/Test/Staging/Prod等環(huán)境，構(gòu)建面向用戶的端到端自動化能力。典型的場景就是交付流水線，示意圖如下：
可以把一個端到端的交付流水線，分成了四個標(biāo)準(zhǔn)化過程，縱向就分解了階段、環(huán)境、動作和角色等概念。
1. 階段
是對交付階段的邏輯劃分，對于一個企業(yè)的某個產(chǎn)品來說，建設(shè)的標(biāo)準(zhǔn)是單一交付流水線，而不是多交付流水線，單一交付流水線才能保證整個交付過程的一致性。一般分成研發(fā)、測試、預(yù)發(fā)布和生產(chǎn)運維階段。
2. 環(huán)境
環(huán)境是以上四個階段的進一步細(xì)分，在每一個階段會存在多環(huán)境的問題，比如說測試階段，有UAT環(huán)境、SIT環(huán)境;在生產(chǎn)階段，有正式生產(chǎn)集群、有容災(zāi)備份集群等等。
3. 動作
交付的能力是動作來實現(xiàn)的，這個動作是一連串的能力編排。這個動作可以分解成部署動作和附加動作。部署動作是完成一個環(huán)境部署的標(biāo)準(zhǔn)化過程，比如說初始化環(huán)境、安裝程序包等等，附加動作是針對特定環(huán)境要完成的一些動作，比如說針對用戶接受性測試，可能會運行自動化測試等等。部署動作要確保在各個環(huán)境之間的一致性，這是部署腳本的基本能力，避免動作行為異化導(dǎo)致結(jié)果不同。
在動作層，還可以面向封裝大量的自動化流程、工具能力等，這些能力都是滿足一切應(yīng)用場景的個性化。
4. 角色
誰來執(zhí)行這些動作，不同的環(huán)境可以面向不同的角色，這是權(quán)限的控制。通常分成開發(fā)、測試和運維角色，但真正到企業(yè)內(nèi)，角色的劃分會細(xì)致的多;其次這個角色也是隨著管理模式變化而變化的，測試人員可能來做生產(chǎn)環(huán)境的部署。
這個自動化能力就不是運維自動化，而是IT自動化。IT自動化的平臺可以由運維來建設(shè)，確保可擴展、插件化的能力。擴展的能力，是能力可以延伸到不同角色的需要，插件化是可以集成不同角色過去的工具能力，從而實現(xiàn)一個面向DevOps的應(yīng)用交付平臺。
再回到運維自動化，在面向應(yīng)用的自動化場景上，依然可以通過服務(wù)編排的模式來實現(xiàn)。但是回到其他運維資源上，就逐漸失去和應(yīng)用的關(guān)聯(lián)，從管理方便性的角度來說，更是如此了。舉個例子，比如說數(shù)據(jù)庫的維護，大家肯定都是喜歡對數(shù)據(jù)庫的實例進行維護和變更，而不是再加一個應(yīng)用的維度。在面向Iaas和PaaS能力的自動化上，可以面向資源進行動作服務(wù)編排，從而實現(xiàn)運維的自動化。
狀態(tài)其實是面向應(yīng)用的一種度量手段，度量越貼近應(yīng)用，越貼近服務(wù)，度量的有效性就越強。監(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)用的運維管理新思維，是切實有效的，給過去的很多未解問題提供了解決方案，這也是我過去不斷強調(diào)要“建立以應(yīng)用運維+運維研發(fā)為核心的組織體系”的原因。應(yīng)用的是貼近業(yè)務(wù)的，因此應(yīng)用是驅(qū)動力***的。
【本文是51CTO專欄作者“王津銀”的原創(chuàng)稿件，轉(zhuǎn)載請注明出處】
