隨著業務的增長、對運維效率和質量的要求不斷提高，對自動化運維體系的需求也不斷增強。
目前筆者服務的很多中大型企業客戶，運維其實還停留在“刀耕火種”的原始狀態。
這裏所說的“刀”和“火”就是運維人員的遠程客戶端，例如 xshell 和Windows 遠程桌面。
這種工作模式有很多局限性，
比如服務器、數據庫、中間件等的安裝、初始化，應用軟件部署、服務發布和監控都是通過手動方式來完成的。
這就需要運維人員登錄到服務器上，壹臺壹臺去管理和維護。
如果有個幾十上百臺，累就累死人了。
筆者曾運維過超過4000千臺服務器，團隊二十多個人，仔細想想這活靠人力能幹嗎？
另外人工操作方式過於依賴運維人員的執行順序和操作步驟，稍有不慎即可能導致生產事故，即便是變更前double check也很難保證不出事故。
常在河邊走哪有不濕鞋。
這時候運維人員開始探索使用使用腳本和批量管理工具。
這種方式確實提升了效率和質量，但是不具有普適性。
第壹是腳本的非標準化的問題。
每個運維人員都有自己的解決問題的風格，不同的人員之間存在巨大差異，那麽不同的人開發這些腳本的版本管理就是壹個挑戰。
第二是腳本的交接問題，公司人員的架構不是壹成不變的，有人來就有人離開。離職和工作交接，都會導致腳本無法很好地在運維人員之間傳承和再利用。
因此，構建自動化運維體系成了唯壹的選擇。
那麽如何建設自動化運維體系呢？本文研究分為三個大的方面：
第壹個是為什麽要建設自動化運維體系？
第二個是根據筆者經驗介紹運維系統是怎樣設計、運行和處理問題的。
第三個是筆者在自動化運維過程中遇到的壹些問題的思考，做壹個總結。
本文針對數據庫自動化運維系統
核心內容如下：
壹、建設自動化運維體系的原因
為什麽要建設壹個自動化運維體系。
肯定是運維過程中遇到的壹些挑戰。
第壹個是變更的需求。
它表現為三個方面:
壹是變更數量多，目前我們服務的客戶達到3萬家企業，這個體量是很大的。
二是變更種類多，不同的客戶需求是不壹樣的，包含但不限於擴容、性能優化、故障處理、DG切換遷移、RAC搭建等。
三是變更風險大，有些變更都是壹些高危操作，自動化處理更安全等。
第二個是運維環境方面，主要表現為服務器數量多、數據庫類型多。我們的客戶可以自由選擇使用哪種數據庫，分別對應不同的環境。
第三是人的因素。
在建設自動化運維體系過程中，有壹個比較重要的考慮點是人的因素。
正是因為每個運維人員的能力不壹樣，技術水平參差不齊，甚至是運維習慣和工具也不壹樣。
導致我們必須要創建壹套規範的自動化運維體系，來提升工作效率。
二、如何搭建自動化運維體系
下面我們來看壹下每個模塊是如何設計和工作的。
1、自動化安裝系統
安裝數據庫是比較繁瑣但數據又多的工作之壹。
操作系統多，但是人少，可用時間也比較少，自動化安裝省時省力。整個自動化流程采用通用的框架，主要是針對linux下的Oracle安裝和MySQL安裝。
交付用戶之前，會進行基本的安全設置，這在壹定程度上提高了安全性，也減少了需要人工做的壹些操作。
2、自動化運維平臺
當服務器由自動化安裝完數據庫以後，就會被自動化運維平臺接管。
自動化運維平臺是運維人員的操作平臺，它主要解決安全、高效、快速等因數量特別多而帶來的管理問題。
在設計的過程中要考慮了以下幾個因素：把整個運維系統的操作界面設計成基於堡壘機的架構。
運維工程師無論何時何地都可以登錄管理系統進行運維操作，這樣的話就比較方便，由SecureCRT對被操作的機器發布指令。
充分利用現有協議和工具。這個平臺的特點是所有的系統使用SSH管理，而不是自己開發壹些Agent，這也體現了自動化運維的觀點。
3、自動化巡檢系統
由於我們的客戶系統比較多，業務也比較多，怎樣設計壹套系統去巡檢它們的運行情況呢？
我們采用了兩種方式：自我開發的中控系統和第三方管理平臺先看自己開發的中控系統：
單獨使用壹臺服務器巡檢其他的數據庫節點，腳本可以選用shell或者Python。
設定遍歷時間間隔，遇到故障情況可以采用打電話或者發短信的方式及時通知運維人員。
第二是把所有的數據庫節點納管到第三方監控平臺。
4、自動化性能分析系統
系統並不用永遠都穩定運行，性能問題是無法逃避的問題。性能分析系統是重中之重。
這裏筆者單獨再寫壹篇文章。
5、自動化監控預警系統
通常客戶的系統都是7*24小時運行的，這就要求必須有預警監控。
預警監控系統+值班人員是標準配置。
預警監控系統的搭建方式參考巡檢系統，只不過采集的指標不壹樣。
6、自動化備份系統
兩地三中心+DG+NBU
三、建設自動化運維體系的思考
筆者將自動化運維體系的建設目標總結為四個詞。
第壹個是完備，這個系統要能涵蓋所有的運維需求。
第二個是簡潔，簡單好用。運維人員的學習成本不要高，越復雜難用的系統越不容易發揮系統本身的能力和效率。
第三個是高效，特別是在批量處理或者執行特定任務時要高效。
第四個是安全，如果壹個運維系統不安全，可能導致很快就被黑客接管了。
總結
筆者目前也在從數據庫的架構、優化和故障處理慢慢轉型做自動化運維體系。
對過去進行總結，我覺得有3個方面可以供大家參考。
第壹是循序漸進的原則：
聚焦當前的問題，把當前的問題處理好，後面的問題也就迎刃而解。
如果壹開始設計的系統很龐大、功能特別豐富，會導致壹些無法控制的局面。但是如果壹開始的目標是解決壹些特定的問題，有針對性，那麽推進起來也會比較簡單。在筆者參與的自動化運維體系建設過程中，我們的初始目標是構建的是壹個基礎的變更批量操作平臺，先把壹部分需要重復執行的工作搬到平臺上來。
再依據運維的需求豐富這個操作平臺的功能和提升效率，最後把周邊的系統打通，相互對接，形成完整的自動化運維體系。第二是考慮可擴展性：
設計系統的時候，功能或者設計方面可能不用考慮那麽多，但是要考慮當服務器數量發生比較大的擴張時，系統是否還能支撐。第三是以實用為目的：
使用不方便，運維人員第壹個就放棄了，何談推廣？
如何搭建數據庫自動化運維體系
標簽：能力兩種ble擴展事故團隊簡潔體系之間