[[282289]]

大多數企業的運維都是基于多年的歷史發展形成今天的局面，不同年代的不同格局和技術發展導致我們沒辦法進行一刀切式的升級換代，在這種情況下，要想實現真正的運維自動化，是不是該先想好自己的運維數據治理問題才能往下進行?

本文中探討解讀來自多位領域內專家和運維老兵分享。

@趙海 技術經理：

運維自動化應該實現哪些目標?

個人認為運維自動化在現階段來講就是要實現運維數據的自動化采集，運維數據的自動化分析，運維監控的自動化和運維告警的智能化，運維工具和運維操作的自動化和智能化。要實現這一系列的事情我覺得必須得以數據為基準，首先就是關于數據采集的問題，不同的終端具有不同格式不容內容的日志數據，目前來講還沒有一個可行的標準來貫徹。接著，就是數據入庫的問題，無論是CMDB還是其他的方式，總而言之要從采集過來的日志進行抽取入庫，將有用的信息入庫格式化，那么如何分清楚是否有用?以什么樣的格式加工入庫比較有意義，我想目前來講CMDB算是比較合理的一種方式，但這是不是最合理的呢?再有，就是對數據的分析，有些數據需要實時報警，有些數據需要結合歷史數據的慣性軌跡來進行分析，有些數據需要長時間積累之后抽取出有意義的性能曲線，有些數據需要結構化的分析，有些數據可能需要結合非結構化的分析。

總而言之，數據的分析也不僅僅是簡單的條件查詢或者累計，需要一種合理的方法和平臺來實現。最后就是關于數據的利用，有了這些數據之后，我們可以根據數據的分析結果來判斷后續的運維操作，無論是故障診斷和處理還是說日常的運維變更批量化，都需要數據的支持，根據不同的數據結果來判斷下一步的精準運維操作，這個過程相信也是需要將邏輯和數據高度結合才能完成的更有意義。

說了這么多，其實貫穿始終的最重要的就是數據的處理，從原數據到不同層面的加工數據，從原始的采集積累到后續的數據分析和處理。對于大多數企業的運維來講都是從好多年的歷史發展形成今天的局面，不同年代的不同格局和技術發展導致我們沒辦法進行一刀切式的升級換代，在這種情況下，要想實現真正的運維自動化是不是該先想好自己的運維數據治理問題才能往下進行?

@jason2006xu 昆侖銀行 技術經理：

運維自動化首先離不開運維對象(IP、網卡、端口等)準確信息以及運維對象之間的關系，這就是CMDB的CI和CI之間的關系。而CMDB建設過程通常會遇到以下幾個問題：

CI信息分散，不同系統保持不同CI信息;CI信息重復，CI信息采集重復，存儲重復。

CI信息不一致不同系統中的CI信息不一致，以哪個為準、其他系統是否可以更新以保證一致是個問題。

CI標準和規范缺失：導致CI模型、存取、識別等混亂無序，CI信息重復采集、無目的采集現象嚴重。

CI信息閉環管理缺失：CI信息的管理是一個循環往復的閉環過程，它的目的是建立CI信息的管理機制，保證CI信息質量的不斷提升。

要想把CI治理好必須是一個長期的過程，伴隨著邊污染、邊治理，所以CMDB建設不是一個項目(臨時、獨特、漸進明晰)，而是一個長期建設的過程，需要有管理長效機制，持續檢查、規范、改造，一遍一遍的來過。

@zjwy82 銀行系統架構師：

首先我表達個人觀點，運維數據統一治理并非自動化的先行條件，需要先把運維數據概念的定義以及自動化運維的覆蓋范圍厘清。我更傾向于配置管理是自動化運維的先決條件。

先說說對運維數據的理解，我認為有幾類，一類是描述生產資源的數據即我們常說的配置數據，另一類是生產資源運行過程中產生的數據。配置數據也可以理解為是數據中心內部的主體，都在圍繞他開展各項工作。這如我們做一次運維需要知道是為哪個對象，是設備加電還是數據庫打補丁或是應用程序版本升級，這里所提到的設備、數據庫軟件、應用都是配置信息的一份子。

自動化運維是一個有廣度有深度的任務，可以有不同角度的細分。按技術架構分層可以有應用部署自動化，基礎軟件部署自動化，計算資源自動化，每一項之間都有互相聯系，也都有特定領域實踐。從深度上就需要考慮自動化串聯、審計、效果度量。一如我們當前所熟悉的云平臺，是一個典型的資源供給自動化/自服務，實現資源供給管理是最基礎的自動化，這僅僅依賴于配置信息管理即可完成。那如果要對資源彈性供給則需要對資源使用、運行支撐業務、應用架構等都有詳細的管理才能做好。所以在不同管理需求/成熟度要求的前提下，自動化對運維數據有不同范圍的依賴。

那有問題說我要做一個最完善的自動化，所以我要做好全運維數據的統一治理。這個問題很復雜，運維數據有很大一部分是由應用程序產生，需要有各種依賴，與組織分工、技術標準以及規劃管理都有很大關聯，可以在分步推動運維數據治理和自動化。

@he7yong 研發工程師：

運維數據統一治理、運維自動化都是非常大的話題，因此，我不贊同運維數據統一治理是運維自動化的先行條件。

建設一個良好的CMDB是運維自動化的先行條件!我是贊同的。

@楊文云 數據庫管理員：

也許問題的意思是運維數據要集中處理，個人經驗覺得這種實現在實踐中不容易實現。運維數據治理確實至關重要，但是集中處理并不合適運維管理平臺化在一個平臺做系統維護，要實現系統的定制，批量管理，日志的標準化，數據分析，量化，還是要定義一些數據分類的，這需要根據應用業務需要分類，量化，個人覺得這樣更靠譜，更有實現的可能性。所以運維管理平臺是自己作為一個系統維護，但是運維數據應該是各個應用系統自己維護治理。

按照標準去做本身沒有什么問題，但是實施起來十分困難，系統的差異性已經存在了，生產上再去標準化不容易實施，就像IPv4到IPv6，是沒辦法一次性完全舍棄ipv4的。需要的是兼容，逐步標準化。而且運維的問題千差萬別，很理想化的場景是設置一些規則能夠通過日志或告警識別出問題 然后采取對應措施，但是我覺得能做到用一個小機器人準確的派發工單就不錯了。主要是綜合和復雜的情況太多了，如果是系統比較穩定，可能自動化運維還比較有效，如果是運維新的比如云項目之類的特殊情況太多了，可能要慎重。

@yujin2010good 大型零售巨頭 系統工程師：

運維自動化和數據治理是兩個方向。

運維自動化是將人為的，重復的勞動用工具簡化，提高生產力。

數據治理重點在數據，沒有自動化運維就做做數據治理了嗎?就不做分析，不出報表了嗎?難道就不要求報表準確了嗎?

當然有統一的數據治理，有統一的標準，這樣可以快速完成工作，并且能做到一些我們更高標準和要求的事情，比如會員畫像，精準營銷等。

@wh85 某大型保險公司 系統工程師：

涉及CMDB和自動化，簡單說幾點拙見：

1、這兩個概念都很廣，做此類項目切忌求大求全。

2、運維自動化要用到的數據是否有機制或工具保證準確?如沒有，則數據治理需要進行。

3、運維自動化范圍如何?數據治理的最小范圍相同。

4、有些運維數據，即便自動化不用，企業或者管理層也需要，這種情況下也需要進行數據治理。

舉幾個例子：

1、應用集群的主機清單，應用部署路徑直接影響到應用自動化的開展，這類數據必須一直準確且有機制保證。

2、應用的干系人有哪些?這些數據也屬于廣義上的運維數據，但也需要保證準確。

3、變更自動化是否需要服務器的機柜信息?機房信息?不需要。但企業資產管理需要。

@zhaogao22 某大型互聯金融安全和運維總監：

哈哈，言論自由哈，個人認為數據化采集和自動化運維并不存在嚴格依賴關系，數據采集是數據采集，自動化運維是自動化運維，兩碼事。

通常自動化運維主要是代替運維工程師來執行某些運維工程師需要干的活，比如上線發布，服務監控，日志采集，數據歸納，故障定位等，可以使用自動化工具，腳本，插件等。

@老同志lawso 企業IT負責人：

不一定。運維自動化是個比較大的話題，很多重復完成的工作都可以通過運維自動化工具來替代，這些工作不一定需要做運維數據治理才能夠實現，可能需要的數據只是和要做的事情有關系。所以有統一治理后的運維數據肯定是很好，如果沒有也沒關系，先將你希望要實現的自動化工作列出來，然后看一下涉及到哪些運維數據，對這些數據做一下梳理和整合，能夠滿足工作的需要就可以了。

@gongpu 某小型城商行 數據庫架構師：

同意，就像大數據要想得出新知識，需要很好的數據治理一樣，運維領域本身的工作量，如果能夠界面可視化，通過腳本或程序大幅度降低人工手動操作已經很好了，至于偶發的故障排查，因為畢竟相對工作量有限，到底是通過案例知識庫，還是沉淀大量數據，找規律自動解決，我覺得是需要評估成本收益的，當然數據治理如果能做好，那是最好的。