NO IMAGE

朋友們調侃說,運維是個把腦袋別在褲腰帶上的活,更有人說,運維是個把腦袋別在他人褲腰帶上的活,苦勞沒人認,有鍋就有得背!

 

測試的同學說,“吃瓜群眾很難感知運維背後的付出,倒是出了事情更能體現我們的專業性。”小樣兒,你這是還沒有掉坑裡過。

 

所以,最好就是減少鍋的出現。

 

但是,鍋來了,大家就得背,甭管你是運維、產品、測試還是開發,總得有個人出來走一走,對吧?

 

今天我們就來談談運維DBA怎樣少背鍋。

 

運維DBA的形勢是很惡劣,但再惡劣也比不過當年紅軍過草地。紅軍當年靠三大紀律八項注意度過了難關,若運維DBA認真執行,也能度過背鍋難關。

 

運維DBA的四大紀律 

 

一、一切行動聽指揮

 

甭管你是團隊,還是團伙,要求都是一樣的,一切行動聽指揮!聽誰的指揮?聽運維經理、運維總監、CTO、CEO的指揮。

 

當年墨子當鉅子的時候,手下180人,訓練有素,同心同德,“赴火蹈刃,死不還踵”。這樣的團隊來搞運維,就具備了基本要求。

 

運維團隊裡,最忌諱的是具有三腳貓功夫、蔑視前輩經驗、心浮氣躁的人,遇到這種人Team Leader要及時校正甚至剔除,否則這就是你背鍋的最大來源。我被坑得比較慘的幾次,都是因為團隊裡有這樣的人,想動手的時候不夠堅決,最後禍起蕭牆,只能弓著腰給客戶和領導死命的批評。這叫什麼,一顆老鼠屎壞了一鍋湯。

 

所以,選擇運維成員時,要選那種踏實、機敏、上進、溝通能力強的年輕人,用心培養,往往事半功倍。

 

二、兩條紅線不能犯

 

所謂紅線,就是天條。第一個是按指揮再行動,其實是活的,可能是要請示和彙報的。這第二條是死的,就像高壓線一樣,碰到就完蛋了。

 

所有變更要做到:凡變更必有方案,凡方案必經過評審方可執行,凡執行必嚴格遵循方案,重大變更需要有人核實。

 

這一條其實是為了規避誤操作,誤操作就是人為故障。人為故障在所有故障中的佔比一直是很高的。

 

所有影響到業務的故障,不管是硬體故障、軟體故障還是人為故障,必須第一時間通知到部門經理。

 

這一條是為了規避,技術人愛鑽牛角尖,看見故障鑽進去就出不來,貽誤戰機,把快速恢復業務的大好時機給浪費了。

 

三、假日前容量規劃

 

記得某一年有一次團隊Outing,集合時某DBA睡眼惺忪地說半夜3點被告警搞起來了。這還不算,他在玩密室逃脫的時候,又接到機房告警電話,某業務表空間使用率超過85%嚴重告警了。是不是亮瞎了?

 

要想輕輕鬆鬆過節日,或者出去玩,除了做好備份之外,最重要的是做好容量規劃。最基本的表空間、檔案系統空間、歷史告警等等基本情況橫掃一遍,起碼要能安全等到你休假回來。

 

對於一些特別的電商系統,節假日可能正是高峰期,那就不僅僅是空間這點事了,還要做好效能預測和解決方案預案。

 

四、備份恢復年年做

 

備份要做,恢復更要做。如果你是管理者,千萬必要以為你的DBA一定會幫你做了。

 

不驚訝,真實案例的脫敏資料:

 

 

如果是企業缺少相應備份裝置或軟體導致的,DBA有義務督促領導購置恢復演練所需的軟硬體裝置。因為一旦出現意外,DBA的直接領導往往也擔不了這個責任,畢竟資料都保護不了,使用者還怎麼相信你這個企業,不論你是央企還是國企。

 

運維DBA的九項注意 

 

三大紀律是規矩-Rules,八項注意是指導原則-Guidance。

 

做運維的人,不能總說這個我們沒想到,哎呀,沒想到這也不行。這是爬雪山,過草地,不注意就陷進去了,哪裡會留時間給你瞎BB?

 

1、對生產環境心懷敬畏

 

你也許沒聽過“一個tnsping幹翻6臺P595”,你也許沒聽過“一個cp命令讓營業系統停止使用30分鐘”,你也許沒聽過“建一個索引讓所有核保業務不能用了”,你也許沒聽過“我本來是要shutdown我的虛擬機器的,沒想關生產庫”… …

 

你沒聽過的事情很多,你沒幹過的事情更多,因為你還年輕。

 

但是一定要對生產環境心懷敬畏。

 

所有操作命令不是網上搜來就可以用的,你要儘可能搞清楚這個命令的副作用,這個命令下去最壞的可能,可能是什麼?不懂的就虛心求教,DBAplus社群這麼多大牛,實在不好意思,就先砸個大紅包過去再問。

 

2、保持24小時開機

 

做運維的沒有徹底休假之說,不要以為你休假了就關機大吉了,那離你關門大吉也不遠了。嗯,所以有些公司把這條也列為紀律之一。

 

我曾遇到過這樣一個情況,某個DBA請假了,剛好有個環境的密碼只有他知道,而這個環境現在出了點問題。可想而知,當時人是多麼著急? 嗯,那個DBA休假回來就長時間離開現場了。

 

3、多請應用的人嘮嘮嗑

 

完全不懂業務的DBA不是一個合格的架構師。

 

要去懂業務、懂應用、懂服務,就一定要跟應用的人嘮嗑、吃飯、抽菸,平時尊重人家,人家願意跟你說,你就越來越熟悉業務。慢慢的,你就可以為推動業務採用更合適的架構方案。

 

4、不要在上班時間做普通變更

 

什麼叫普通變更?就是你本來可以提前一天做的變更。

 

比如擴表空間、增加使用者許可權、建立索引……並非是為了解決緊急故障而導致的變更。

 

提前做好變更規劃,儘量爭取每次免考核時做完所有重要的變更。

 

5、定期做好資料庫檢查

 

資料庫沒有發生故障,不代表是DBA做得好,而是故障自己還沒有發生,不是不報,實時候未到。

 

所以,確定好檢查規則,定期做好資料庫檢查,並進行整改。涉及到其它配合方的整改一定要郵件抄送,並電話確認。

 

6、資料庫部署要給予最小化許可權

 

安裝必要的最少元件,賦予必要的最小許可權,是主動避坑的有效手段。很多資料恢復,操作問題,如果能夠從許可權上把把關,後面就能省很多事情。

 

7、所有的保障手段,都要去驗證其持續可行性

 

部署了高可用系統,上線前要做高可用切換測試。

 

部署了容災系統,要做定期容災演練。

 

部署了應急系統,要做定期應急演練。

 

做了資料庫備份,要做定期資料庫恢復測試。

 

說起來容易,做起來難。全國90%的系統沒有做到這一點。所以你才會經常聽到異常恢復的案例。特別是哪些用儲存容災,或者用OGG應急的。不是技術本身不行,而是管理不行。

 

8、絕盡全力推行自動化運維

 

在看到這條之前,你也許心裡一直在暗暗的罵道,都什麼時代了,還這麼古板。

 

其實不管你是否已經開始了自動化運維,前面的每一條都值得你好好去做好,對你有益無害。

 

但是,去做自動化運維,是運維DBA繞不開的路徑。就像從昆明到上海,最開始是隻能靠馬幫,後來逐漸通了高速公路,現在開始滬昆高鐵了一樣。

 

這個自動化運維怎麼做?完全靠自己重複造輪子顯然不完全靠譜。如果你不是BAT,也不是京東新美大餓了麼,最好的方式,是找專業運維的公司研發的自動化運維平臺,是騾子是馬拿出來遛兩下,你就喜歡上了。

 

9、起步始於交流,收穫源於分享

 

做過講師的人,都會有這樣一個共識,就是講完東西,自己其實比聽課的“學生”收穫更大。這一點網際網路公司做得非常好,不管是BAT還是新的巨頭,都紛紛成立技術學院,領銜的也往往是業界大佬,把企業內部的技術分享組織得有聲有色。

 

作為傳統企業的DBA來說,一家企業往往沒有這麼個學院,但是網際網路上的平臺很多,比如DBAplus社群,甚至還有其他一些社群都提供這樣的機會。

 

為什麼我們團隊工作一年的新人,可以擁有其他公司工作四五年DBA所具有的能力,除了複雜的硬體環境外,每月的分享也功不可沒。

 

運維沒有盡頭,注意事項也沒有盡頭,你有更好的建議,不妨說說。

http://dbaplus.cn/news-21-1077-1.html?utm_source=tuicool&utm_medium=referral