之前分享過一篇元資料管理的文章
如果伺服器不多，或者人也不多，基本都是按照下面的方式來管理。
比如下面是14臺伺服器，會在特定的伺服器（比如中控）設定乙個專門的路徑來存放乙個檔案，即伺服器列表資訊，然後把對應的責任人都劃分出來。
當然這種方式是比較簡單，也看起來確實很清晰，對於基本的管理應該是沒有問題，但是一旦發生了資訊的變化，這部分資訊就比較容易出現遺漏，比如伺服器2出現了問題，做了故障退還，那麼就需要張三在伺服器列表中標註為故障退還，可能後面給他新分配了一台伺服器，他也可能沒有記錄新的伺服器到這個檔案裡面，或者沒有標註故障歸還的伺服器。
如果李四來幫助張三臨時處理問題，那麼這個時候這些資訊就無從知曉，也不好跟進。或者張三把某台伺服器的歸屬列為李四，也沒有通知李四，沒有問題大家都相安無事，但是一旦出現問題，這種責任歸屬和問題的劃分就會比較鬆散。
那麼一種改進思路就是需要有乙個專員來協調負責這些元資料的管理。機器的申請，退還肯定要有流程，那麼這些流程的乙個觸發器就是資產資訊的變更，這些都需要跟隨資產資訊變更來在列表中得到體現。但是張三李四王五沒有直接的許可權來修改這些資訊，可以提出申請修改，需要有乙個審核的過程。
無規矩不成方圓，如果有成千上萬臺，那麼這種集中-分布式的管理就尤為重要。
這些伺服器資訊終歸還是需要放到乙個共享的目錄中，大家都可以檢視。從這個演變來看就是excel和資料庫中儲存資訊的差別了。
那麼對於每個負責來說都是關注自己的那一畝三分地為主，所以需要從這個共享的檔案中得到屬於自己的那一部分資訊來。
然後在這個基礎上進行針對性的檢查和問題處理，比如硬體監控，比如oracle資料庫監控，mysql監控等。
一種方式就是採用本地傳送指令碼的方式，這種方式有點類似jdbc的感覺，就是通過ssh能夠連線到遠端伺服器，然後把需要傳送的指令碼內容一併傳送過去，這種方法的有點狠明顯，就是依賴性很小。而且可擴充套件性強。如果指令碼不大不多的情況下還是優選。
還有一種是類似agent的方式，就是在每台伺服器端都部署乙個類似的agent,每個agent中都包含有這些相關的指令碼內容。直接通過遠端呼叫的方式就可以得到結果。
這種方式對於大批量的指令碼，複雜的功能需求還是比較通用。
需要說明的是，這些共享的伺服器資產資訊是放在了資料庫中。
從目前的元資料管理的情況來看，其實對於每個人來說，還是主要關心自己負責的伺服器，就需要從共享檔案中生成屬於自己的伺服器列表資訊，而且這些伺服器資訊還可以隨著資產資訊變化而變化，不要求實時，但是要求這些變化能夠體現出來。然後基於此來實現特定的業務管理需求。
後續來分享乙個比較奇怪的元資料抽取的案例。
運維平台的建設思考 元資料管理
之前也寫過一篇比較基本的文章，也算是自己對運維平台的乙個基本思考。當然想法簡單，而且缺乏實踐，但是朝著這個方向邁進是沒有錯的。從我的觀點來看，現在能夠實現半自動化運維已經很了不得了。而且把這些工作能夠落到實處，更是不易 比如舉幾個簡單的例子。比如對於資料庫的資料檔案新增這個功能來說，其實完全可以實現...
運維平台的建設思考
自己最近也在琢磨如何搭建出乙個完善有效的運維平台，當然這個工作不是一朝一夕就能完成，前行的道路上肯定會有各種各樣的困難和牽絆，但是自己還是能夠學以致用，把一些重複性，繁瑣性的工作都能解放出來，能夠更加關注於更高的乙個層級來看待整個系統。我把搭建運維平台的過程分成了5個階段，當然純粹是個人之見，難免有...
運維平台的建設思考 元資料管理 r7筆記第57天
之前也寫過一篇比較基本的文章，也算是自己對運維平台的乙個基本思考。比如舉幾個簡單的例子。比如對於資料庫的資料檔案新增這個功能來說，其實完全可以實現自動化擴容。但是是否完全可行呢，我覺得還有待斟酌。比如temp設定為自動增長，如果出現 了sql語句導致的問題，結果導致temp被撐爆，聽說過temp無限...