運維平臺的建設思考-後設資料管理（二）

之前分享過一篇後設資料管理的文章 http://blog.itpub.net/23718752/viewspace-1960938/
如果伺服器不多，或者人也不多，基本都是按照下面的方式來管理。
比如下面是14臺伺服器，會在特定的伺服器（比如中控）設定一個專門的路徑來存放一個檔案，即伺服器列表資訊，然後把對應的責任人都劃分出來。

當然這種方式是比較簡單，也看起來確實很清晰，對於基本的管理應該是沒有問題，但是一旦發生了資訊的變化，這部分資訊就比較容易出現遺漏，比如伺服器2出現了問題，做了故障退還，那麼就需要張三在伺服器列表中標註為故障退還，可能後面給他新分配了一臺伺服器，他也可能沒有記錄新的伺服器到這個檔案裡面，或者沒有標註故障歸還的伺服器。
如果李四來幫助張三臨時處理問題，那麼這個時候這些資訊就無從知曉，也不好跟進。或者張三把某臺伺服器的歸屬列為李四，也沒有通知李四，沒有問題大家都相安無事，但是一旦出現問題，這種責任歸屬和問題的劃分就會比較鬆散。
那麼一種改進思路就是需要有一個專員來協調負責這些後設資料的管理。機器的申請，退還肯定要有流程，那麼這些流程的一個觸發器就是資產資訊的變更，這些都需要跟隨資產資訊變更來在列表中得到體現。但是張三李四王五沒有直接的許可權來修改這些資訊，可以提出申請修改，需要有一個稽核的過程。

無規矩不成方圓，如果有成千上萬臺，那麼這種集中-分散式的管理就尤為重要。
這些伺服器資訊終歸還是需要放到一個共享的目錄中，大家都可以檢視。從這個演變來看就是excel和資料庫中儲存資訊的差別了。
那麼對於每個負責來說都是關注自己的那一畝三分地為主，所以需要從這個共享的檔案中得到屬於自己的那一部分資訊來。
然後在這個基礎上進行鍼對性的檢查和問題處理，比如硬體監控，比如oracle資料庫監控，MySQL監控等。
一種方式就是採用本地傳送指令碼的方式，這種方式有點類似JDBC的感覺，就是通過ssh能夠連線到遠端伺服器，然後把需要傳送的指令碼內容一併傳送過去，這種方法的有點狠明顯，就是依賴性很小。而且可擴充套件性強。如果指令碼不大不多的情況下還是優選。

還有一種是類似agent的方式，就是在每臺伺服器端都部署一個類似的agent,每個agent中都包含有這些相關的指令碼內容。直接通過遠端呼叫的方式就可以得到結果。
這種方式對於大批量的指令碼，複雜的功能需求還是比較通用。

需要說明的是，這些共享的伺服器資產資訊是放在了資料庫中。
從目前的後設資料管理的情況來看，其實對於每個人來說，還是主要關心自己負責的伺服器，就需要從共享檔案中生成屬於自己的伺服器列表資訊，而且這些伺服器資訊還可以隨著資產資訊變化而變化，不要求實時，但是要求這些變化能夠體現出來。然後基於此來實現特定的業務管理需求。
後續來分享一個比較奇怪的後設資料抽取的案例。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1989825/，如需轉載，請註明出處，否則將追究法律責任。