[[282289]]

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

本文中探討解讀來自多位領(lǐng)域內(nèi)專家和運維老兵分享。

@趙海 技術(shù)經(jīng)理：

運維自動化應(yīng)該實現(xiàn)哪些目標(biāo)?

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

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

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

@jason2006xu 昆侖銀行 技術(shù)經(jīng)理：

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

CI信息分散，不同系統(tǒng)保持不同CI信息;CI信息重復(fù)，CI信息采集重復(fù)，存儲重復(fù)。

CI信息不一致不同系統(tǒng)中的CI信息不一致，以哪個為準(zhǔn)、其他系統(tǒng)是否可以更新以保證一致是個問題。

CI標(biāo)準(zhǔn)和規(guī)范缺失：導(dǎo)致CI模型、存取、識別等混亂無序，CI信息重復(fù)采集、無目的采集現(xiàn)象嚴重。

CI信息閉環(huán)管理缺失：CI信息的管理是一個循環(huán)往復(fù)的閉環(huán)過程，它的目的是建立CI信息的管理機制，保證CI信息質(zhì)量的不斷提升。

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

@zjwy82 銀行系統(tǒng)架構(gòu)師：

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

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

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

那有問題說我要做一個最完善的自動化，所以我要做好全運維數(shù)據(jù)的統(tǒng)一治理。這個問題很復(fù)雜，運維數(shù)據(jù)有很大一部分是由應(yīng)用程序產(chǎn)生，需要有各種依賴，與組織分工、技術(shù)標(biāo)準(zhǔn)以及規(guī)劃管理都有很大關(guān)聯(lián)，可以在分步推動運維數(shù)據(jù)治理和自動化。

@he7yong 研發(fā)工程師：

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

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

@楊文云 數(shù)據(jù)庫管理員：

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

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

@yujin2010good 大型零售巨頭 系統(tǒng)工程師：

運維自動化和數(shù)據(jù)治理是兩個方向。

運維自動化是將人為的，重復(fù)的勞動用工具簡化，提高生產(chǎn)力。

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

當(dāng)然有統(tǒng)一的數(shù)據(jù)治理，有統(tǒng)一的標(biāo)準(zhǔn)，這樣可以快速完成工作，并且能做到一些我們更高標(biāo)準(zhǔn)和要求的事情，比如會員畫像，精準(zhǔn)營銷等。

@wh85 某大型保險公司 系統(tǒng)工程師：

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

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

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

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

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

舉幾個例子：

1、應(yīng)用集群的主機清單，應(yīng)用部署路徑直接影響到應(yīng)用自動化的開展，這類數(shù)據(jù)必須一直準(zhǔn)確且有機制保證。

2、應(yīng)用的干系人有哪些?這些數(shù)據(jù)也屬于廣義上的運維數(shù)據(jù)，但也需要保證準(zhǔn)確。

3、變更自動化是否需要服務(wù)器的機柜信息?機房信息?不需要。但企業(yè)資產(chǎn)管理需要。

@zhaogao22 某大型互聯(lián)金融安全和運維總監(jiān)：

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

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

@老同志lawso 企業(yè)IT負責(zé)人：

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

@gongpu 某小型城商行 數(shù)據(jù)庫架構(gòu)師：

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