大神教你如何構建面嚮應用的營運管理新思維

大神教你如何構建面嚮應用的營運管理新思維
導讀營運需要思維的突破，從Ops走向DevOps，從項目走向產品，從資源走嚮應用，很多問題一直在困擾、在思考，為什麼CMDB大部分項目都是失敗的?為什麼討論的更多的是營運自動化而不是IT自動化?為什麼線上問題永遠是營運人的黑鍋?帶著這些問題我們來一探究竟。

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

在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