運維DBA的4大紀律9項注意【轉】

運維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所具有的能力，除了複雜的硬體環境外，每月的分享也功不可沒。

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

本文轉自 lirulei90 51CTO部落格，原文連結：http://blog.51cto.com/lee90/1957207，如需轉載請自行聯系原作者