資料中心運維:減少折騰就是降低故障
“沒有折騰,就沒有故障”這句話雖糙,但卻很有道理,尤其在運維上。據有關諮詢機構統計,資料中心的故障中有百分之七十是人為故障,也就是與人的活動強相關,可見人對於資料中心來說是多麼可怕。人為故障其中也可以分為有意的和無意的。有意的是指明知道一些操作會造成資料中心故障,仍執意去做的,這些人往往希望透過造成資料中心執行癱瘓,而達到不可告人的目的,這種故障佔到了人為故障的80%,剩餘的就是無意的。
資料中心本身是一個複雜龐大的系統,運維的人員不可能面面俱到都精通所有技術細節,當接觸到自己不熟悉或不瞭解的地方,操作易引發意想不到的結果。還有不少的裝置,軟體質量不高,反覆操作下發就容易引發軟體問題,從而造成業務中斷。這種情況在資料中心裡還不少見,資料中心裡裝置成千上萬,數量龐大,動一動問題就來了,所以執行穩定的資料中心不要輕易去改動,就讓它自己處於最佳狀態去執行下去。
眾所周知,但凡遇到一些重大節日和活動,大型的資料中心都會進行封網,停止一切操作和活動行為,目的就是為了減少故障發生,將人為操作風險降低,將觸發BUG的風險降低。這種方式行之有效,除了可能出現一些硬體故障外,幾乎很少發生其它類問題。
我們都知道烏龜的壽命很長,活上幾百年輕飄飄的,就是因為烏龜很少動,移動緩慢,這大大延長了它的生存壽命。資料中心運維也喜靜不喜動,少動慎動,這能最大程度減少故障發生。金融銀行業的資料中心對可靠性要求很高,為了避免出故障,銀行的資料中心內部制定了嚴格的操作制度,所有的操作都要遵守統一規範,任何命令的下發和變更都要經過行裡提前稽核,甚至在模擬環境中驗證過沒問題,才開始到現網中去實施操作,銀行業的資料中心操作最為規範,使得資料中心的可靠性也最高。
不過,為了快速響應業務需求和提高資源利用率,運維又不得不頻繁折騰,不動基本做不到。一個資料中心可能每週晚上都有安排變更,還有裝置軟體升級、配置最佳化、裝置替換等工作,資料中心總是有沒完沒了的變更操作,這樣不可避免地在操作過程中出現一些新問題,導致資料中心總是無法穩定下來,業務經常受到影響,這其實就違背了運維祖訓的宗旨。
資料中心裡需要的技術知識太多,涵蓋多個學科幾十個門類,沒有誰能全部掌握,完全掌握一門都很難,這時制定相應的操作,受限知識面,總會有考慮不周的地方,一旦有漏掉就可能在操作過程中產生問題。對於變更操作,任何人都沒有絕對的把握,凡事都可能有意外,就像是做手術,再小的手術也是有風險的,也要家屬簽字,萬一出了事故手術操作者能免責。
既然不能避免折騰,那就想辦法不讓折騰出問題。
首先要分治。分治就是把風險高的和風險低的分開、重要性高的和不高的分開、簡單的和複雜的分開、頻繁變動的和不頻繁的分開。歸根到底都在做兩件事:封裝複雜度、隔離變化。運維架構層的分治,在業界已經非常普遍了,比如應用伺服器和資料庫伺服器分離、交易資料庫和使用者資料庫分離,生產環境和測試環境隔絕。資料中心是有很多小系統組成的,相互之間要松耦合,最好是隔離的,這樣一個小系統故障,影響是區域性的,不會影響全域性。
其次是管人。要減少人為折騰出的故障,就要加強對人的約束和管理。不同技術等級的人能做的操作許可權是不同的,一個新手要上線操作,必須要由老工程師來指導。要制定詳細的人員管理規章制度,對運維的人員形成約束力,對運維的人員進行考核、監控、管理,增強運維人員工作的責任心,有獎有罰。制定嚴格的各項規章制度,一般的資料中心都需要24小時常年不間斷向外提供服務,所以要給資料中心人員充分的休息時間,按時的上下班,避免長時間工作、疲勞工作,減少出錯機率。
第三是管事。當資料中心需要變更和最佳化操作時,需要運維團隊的人員進行整體討論,對預知的風險進行分析,確保操作不會對執行業務造成影響。每個變更都是整個技術團隊的討論透過做出的決定,而不是個人的行為,這樣能將技術性人為故障降到最低。要制定好回退方案,一旦出現異常情況立即回退,事後將原因分析情況後再進行二次變更。畢竟運維的人員都不是專業搞裝置的,對裝置內部處理和實現並不見得很清楚,重大的變更操作可以邀請裝置廠家的技術人員參與和支援,降低操作錯誤的風險。每次操作都要做好充分準備,必要的模擬演練、提前的業務搬移、緊急通道的準備等都需要,這樣才能降低故障發生的風險。
“沒有折騰,就沒有故障”是金口良言,聽上去很有道理,實際卻很難做得到。資料中心本就是一個資料高速流動的場所,業務需求時時都在變化,為了滿足業務部署和發展的需求,不讓對資料中心變更、折騰,根本就是做不到,“沒有折騰”只是一種理想的狀態罷了。不過,的確是應該最大限度地去主動降低資料中心操作頻率,儘量少動,這樣可極大降低故障發生機率。人是資料中心活動中的最重要因素,沒有人的參與哪裡來的資料中心,而偏偏人也同時給資料中心帶來成長的煩惱,人在運維的過程中作用依然舉足輕重。作為資料中心的運維人,要時刻牢記祖訓。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31509936/viewspace-2168794/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Coco學程式設計(三)--冒泡就是折騰 (轉)程式設計
- 智慧運維,雲資料中心運維的未來之路運維
- 少走彎路少跳坑——資料治理對運維資料體系的思考與啟發運維
- Oracle 19C OGG基礎運維-07減少複製表Oracle運維
- Linux折騰Linux
- 折騰日記
- waydroid折騰
- 減少運維工作量,如何透過 ROS 輕鬆實現資源編排新方式運維ROS
- 資料庫的智慧化運維和故障平臺預測資料庫運維
- 【devops】智慧運維就是由 AI 代替運維人員?dev運維AI
- Hackintosh (黑蘋果) 折騰蘋果
- 折騰樹莓派樹莓派
- 不要太折騰程式
- UGNX折騰筆記筆記
- 【折騰】github+jekyll搭建靜態網站(還沒折騰完),折騰不下去了,求解救Github網站
- 資料中心運維人的半衰期危機運維
- DevOps,就是開發吃掉運維?dev運維
- 雲端計算:拼的就是運維!運維
- AcrelEMS-IDC資料中心綜合能效管理系統減少資料中心電氣安全事故
- nvim 折騰筆記 2筆記
- Oracle資料庫減少redo日誌產生方式Oracle資料庫
- 銀行資料中心全棧智慧運維方案全棧運維
- 如何做好大型資料中心的運維運維
- 大資料的運算加減乘除大資料
- 「機器學習速成」正則化:降低模型的複雜度以減少過擬合機器學習模型複雜度
- VS Code折騰記 - (1)扯淡
- 折騰oracle的em3Oracle
- 折騰oracle的em2Oracle
- 折騰oracle的em1Oracle
- hexo fluid主題折騰HexoUI
- 北京供銷大資料集團探索資料中心運維“新趨勢”大資料運維
- Oracle RAC日常運維-DATA磁碟組故障Oracle運維
- 運維累了:該故障自愈出場了運維
- 使用MVVM減少控制器程式碼實戰(減少56%)MVVM
- ES6折騰記- 模板字串字串
- VSCode折騰log外掛VSCode
- 部落格園主題折騰記
- 虛擬化運維工具雲安:資料中心整合功能運維