之前也寫過一篇比較基本的文章，也算是自己對運維平台的乙個基本思考。當然想法簡單，而且缺乏實踐，但是朝著這個方向邁進是沒有錯的。從我的觀點來看，現在能夠實現半自動化運維已經很了不得了。而且把這些工作能夠落到實處，更是不易 。
比如舉幾個簡單的例子。
比如對於資料庫的資料檔案新增這個功能來說，其實完全可以實現自動化擴容。但是是否完全可行呢，我覺得還有待斟酌。比如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，其它共享儲存等。
備份情況，系統的備份情況，資料的備份情況等等。
當然從資料庫的層面進行更多的思考，需要做到具體的事情就更多了，我們後續再做補充。
最後說一句，聖誕快樂，其實提這個節日的人多，過節的少，該加班加班，幹睡覺睡覺，生活快快樂樂，天天都是節日：）
運維平台的建設思考 元資料管理（二）
之前分享過一篇元資料管理的文章 如果伺服器不多，或者人也不多，基本都是按照下面的方式來管理。比如下面是14臺伺服器，會在特定的伺服器 比如中控 設定乙個專門的路徑來存放乙個檔案，即伺服器列表資訊，然後把對應的責任人都劃分出來。當然這種方式是比較簡單，也看起來確實很清晰，對於基本的管理應該是沒有問題，...
運維平台的建設思考
自己最近也在琢磨如何搭建出乙個完善有效的運維平台，當然這個工作不是一朝一夕就能完成，前行的道路上肯定會有各種各樣的困難和牽絆，但是自己還是能夠學以致用，把一些重複性，繁瑣性的工作都能解放出來，能夠更加關注於更高的乙個層級來看待整個系統。我把搭建運維平台的過程分成了5個階段，當然純粹是個人之見，難免有...
運維平台的建設思考 元資料管理 r7筆記第57天
之前也寫過一篇比較基本的文章，也算是自己對運維平台的乙個基本思考。比如舉幾個簡單的例子。比如對於資料庫的資料檔案新增這個功能來說，其實完全可以實現自動化擴容。但是是否完全可行呢，我覺得還有待斟酌。比如temp設定為自動增長，如果出現 了sql語句導致的問題，結果導致temp被撐爆，聽說過temp無限...