運維需要思維的突破，從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能力的自動化上，可以面向資源進行動作服務編排，從而實現運維的自動化。

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

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

作者：老王

文章出處：網際網路運維雜談（訂閱號ID：waynewang_ops）