961
運維DBA的4大紀律9項注意
朋友們調侃說，運維是個把腦袋別在褲腰帶上的活，更有人說，運維是個把腦袋別在他人褲腰帶上的活，苦勞沒人認，有鍋就有得背！
測試的同學說，“吃瓜群眾很難感知運維背後的付出，倒是出了事情更能體現我們的專業性。”小樣兒，你這是還沒有掉坑裏過。
所以，最好就是減少鍋的出現。
但是，鍋來了，大家就得背，甭管你是運維、產品、測試還是開發，總得有個人出來走一走，對吧？
今天我們就來談談運維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所具有的能力，除了複雜的硬件環境外，每月的分享也功不可沒。
運維沒有盡頭，注意事項也沒有盡頭，你有更好的建議，不妨說說。
原文發布時間為：2017-02-23
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-15 10:02:58