之前也寫過一篇比較基本的文章，也算是自己對運維平臺的一個基本思考。當然想法簡單，而且缺乏實踐，但是朝著這個方向邁進是沒有錯的。從我的觀點來看，現在能夠實現半自動化運維已經很了不得了。而且把這些工作能夠落到實處，更是不易。
比如舉幾個簡單的例子。
比如對於資料庫的資料檔案新增這個功能來說，其實完全可以實現自動化擴容。但是是否完全可行呢，我覺得還有待斟酌。比如temp設定為自動增長，如果出現了sql語句導致的問題，結果導致temp被撐爆，聽說過temp無限擴充套件達到TB級的問題，最後還是sql語句的問題導致。
那麼這個資料檔案是否支援擴充套件，怎麼擴充套件，這個應該一方面是根據系統資源進行權衡，另一方面就得根據具體的系統情況來決定了。這也就引申出我今天想說的關於後設資料的管理。
順便講個小段子，幾個同事跑過來找我，說有一個緊急操作需要DBA配合，然後想讓我去和他們開個會，我就不喜歡那種沒有結果的會議討論，從DBA的角度來說，提供完整的操作步驟，正確的指令碼，你們來評估業務可行性，我們來評估從安全，效能，業務上是否需要支援和改進，當然我說的也很簡單，我就是個幹活的，你來提供詳細的步驟和參考，我來評估和執行，會我還是不參加了吧。其實話說回來，如果我們只是簡單評估和執行，那麼我們工作的含金量會大大降低，外企都很強調的design，DBA也是需要加強這方面的功底的。老是搬磚，時間長了就只會搬磚了。
所以這些design的工作怎麼做，不是一下子高屋建瓴，我們來想想我們能夠做些什麼。從整個運維繫統，運維平臺的角度來考慮，後設資料管理還是根本，但是似乎沒有什麼人重視。
從我的角度來講，我認為後設資料的管理，除了資產層面的資源狀態管理，從運維平臺來說，還是有很多值得注意的地方。
我大體列舉了一部分，從我的角度來看認為還是非常有必要去考慮的。

這些後設資料看起來非常瑣碎，但是一旦管理起來，作用就非常巨大了。比如給你最短的時間做資源盤點，檢視當前的5000臺伺服器中哪些伺服器是在redhat的某個子版本，簡單評估是否可以升級等等。這些沒有後設資料管理，簡直不可想象。所以我把後設資料的考慮劃分成了下面的幾個部分，當然還需要不斷完善。
系統情況，核心版本，補丁，作業系統版本。
硬體配置：基本的硬體配置情況

cpu cpu合數，物理CPU數

記憶體記憶體大小

swap分割槽設定：swap分割槽的設定，swap的大小是否合理，如果是在有些雲伺服器中，預設是不開啟swap的。

磁碟分割槽設定：磁碟分割槽的情況，盤數，raid級別等

crontab：自動任務的情況，是否有ntp的自動同步，是否有定時的業務排程，是否有定時的備份和系統檢查。

防火牆：防火牆開設的埠，開放的客戶端

主機名：伺服器的主機名管理，尤其是在很多系統遷移中，做了大量的主從切換等情況下，有時候從主機名根本分不出來一臺伺服器到底是主庫還是備庫。

ip配置內網外網，網路ip的設定，/etc/hosts中的配置，比如在mysql中的主機名dns許可權解析。如果主從切換之後，是否備庫一定會有主庫所擁有的許可權。

主備，主從關係配置：主從切換之後，是否從庫或者備庫一定能夠勝任，備庫是否已經完全做好了時刻切換的準備。根據主庫是否能夠找到匹配的備庫，或者根據備庫關聯到主庫。

核心引數配置，核心引數的設定，是否初始化的時候已經合理規劃還是根據感覺想到哪裡做到哪裡。有些核心引數設定是否是按照系統硬體資源來設定，是否考慮周全。之前就碰到過一個資料庫程式數設定為150，但是資源配置非常好，但是自己申請調高process之後重啟資料庫的時候，發現原來的核心引數就取的預設值，所以資源好，但是軟體層面的效能跑不上去。

埠配置：對於資料庫來說，開放了哪些埠，哪些埠處於閒置狀態

資料庫引數 init.ora my.cnf，對於oracle,mysql而言，引數的管理也很有必要，如果一臺伺服器當機，想找到之前的一些完整配置，不一定備庫的就和主庫一樣，到底哪裡不同，哪些引數可能設定不和規範，透過統一的引數管理就可以得到一些答案，比如對於oltp,olap來說，哪些引數需要考慮，10g，11g中的特性引數如何取捨，哪些需要統一。

外部檔案掛載，系統中是否有外部的掛載點，比如nfs，其它共享儲存等。

備份情況，系統的備份情況，資料的備份情況等等。

當然從資料庫的層面進行更多的思考，需要做到具體的事情就更多了，我們後續再做補充。
最後說一句，聖誕快樂，其實提這個節日的人多，過節的少，該加班加班，幹睡覺睡覺，生活快快樂樂，天天都是節日：）

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

相關文章