咱們先來分享一波踩坑遭遇，讓同病相憐的童鞋有個機會彼此擁抱，至於如何終結這些飽含血淚的踩坑歷程……（悄悄告訴你們，
後文有驚喜！）那些年的辛酸史
踩坑1號
起初我只是看熱鬧，結果……後來我成了熱鬧……
有一段時間公司缺Hadoop運維人員，作為Hadoop運維的我，週末開始嘗試在服務器上搭建集群。
當時搭的感覺沒啥，到了轉天上班，一到公司就發現我們部門領導周圍圍了一圈人。我放下包坐下來一打聽，才知道xxx集群不可用了，線上應用全部報錯，我當時還跟同事開玩笑說，這麼重要的集群怎麼會出問題，這弄壞的人會不會給處分被開除啊。
然後我就坐下來聽他們一直在討論，他們說前一天下午4點開始報錯的，領導還在那兒上服務器檢查東西，發現Namenode被格式化了。
領導就問我們昨天誰操作了，我說我在其他服務器上搭建集群來著，頓時我有點莫名的恐慌。然後領導去那臺服務器上查，突然說：我嚓，你配置文件是不是從那個集群拷的（出事的集群）？我說是啊，說完我就意識到，完蛋了……配置文件沒改完，在搭建集群的時候有一步給格……式……化……了……
我當時直接蒙圈了，現在想想都覺得好丟人。可能你們會問後來怎樣了，但我什麼都不想說，只能告訴你我有個好領導，把這個事兒擺平了，論好領導的重要性……
踩坑2號
腦子斷片，有一種英雄氣短、死於非命的悲慘感
公司DB2數據庫，生產跨庫Load遊標數據忘記加Nonrecoverable，導致表空間掛起，還是挺大的一個表空間。還好備份表空間時間不長，影響作業不多。有時腦子斷片，操作時關注點集中在自以為高大上的知識點上，忽略基本準則。有一種英雄氣短、死於非命的悲慘感。
踩坑3號
當時腿都軟了，差點就要跑路
公司自用的流媒體服務器遇到故障，網站無法訪問，後面確認是文件掛載問題。我測試時建了個軟鏈接測試，測試完確認問題後rm -rf軟鏈接，結果就在兩秒後我意識到問題，馬上按了Ctrl+C，我擦，視頻被我刪了差不多200g……這個網站不是我負責維護的，是我們女同事在維護，如果是我，我會做定時備份，而她視頻沒有備份。當時腿都軟了，差點要跑路。後面找到辦法，就是重新在Web上傳，重新轉碼，搞了我一個週末，謝天謝地。
踩坑4號
要不是我活好，當時我就哭了
記憶猶新的之前在用Icinga（類似於Nagios）做監控的時候，有一次刪除配置文件時，一不小心將整個配置目錄刪掉了！我擦……當時都快哭了，幸虧活好，主機信息文檔又全面，不到3個小時就恢復了。之前考慮過用開源的恢復軟件，考慮到要Unmout磁盤，但是風險都太高，最後放棄了。
前事不忘後事之師啊，現在的風格絕對妥妥的。尼采說過：What does not kill you makes you stronger，所以說，坑還是有價值滴！
踩坑5號
全公司開發組看著我撞坑，我內心是絕望的
那個時候是被老大抓去幫忙同組裡開發的另一條產品線上的組織樹，數據雖然在緩存裡，但是特定時候對於業務有冗餘，雖然只要展示有用的組織結構，但還是要保持完整的樹狀，不能斷開。
自己想好了算法去過濾有用的組織，再把斷開的組織樹分支接起來。本地測試，測試同學都沒測試出問題，結果上線之後發現一臺機器CPU跑滿了！我們公司監控是直接展示在開發大廳門口的，全公司開發組都能看見。你知道當時我有多絕望嗎？被老大罵得狗血淋頭，拿下來Dump日誌分析，最後折騰出來後才發現原來是贓數據導致，也就是A的上機是B，B的上機是A……結果就是找的死循環了……
踩坑6號
從此再也不相信第三方了
我的坑是隊友造的鍋！最坑的那次是版本1.0.2的時候，一個機器的硬件識別功能突然走不下去，1.0.1還好好的。接著組長拉著我週六加班到十一點，週日上午繼續調試！
到最後，我們才發現是硬件供應商的底層接口悄悄改了變量名！問題是之前問底層有無修改是再三保證沒問題，當undefined提示出來後就無話可說了。從此再也不信第三方的鬼話了，必親調！
踩坑7號
4K+的數據對象灰飛煙滅……
去年一個項目是與某企業活動目錄AD有關的（AD是個類似於數據庫的概念），要開發一個AD的Web控制檯，其中包含了刪除AD對象的功能。有天下午，還未完全清醒的時候登錄了服務器，然後部署新版本，結果手賤點了刪除功能，對跳出的確認框連看都沒看就點了Y。突然不知怎麼就覺得有什麼地方不對了，10秒後，4K+的數據對象灰飛煙滅
，瞬間睡意全無！十多分鐘後，又注意到這是測試服務器，沒有連接到正式環境，萬幸……然後重新導入數據吧。
五
勞 動 節 ？ 勞 動 劫 ？
不知這些血淚史中可有你的身影？總的來說，踩坑的原因千奇百怪，避坑的本質九九歸一，要想從根本上解決這些苦逼遭遇，就要抓住要點，從思路上減少踩坑的可能性。
為此，我們特別請到DBAplus社群聯合發起人、《Oracle DBA工作筆記》作者楊建榮老師，就運維工作中的經驗和教訓總結出了一些思考，從思路上給出了技術人都通用的寶貴建議：
對自己的思考
在運維工作中，我也經歷和變換了一些角色，對我來說，行業裡大家都彼此熟悉，我也會偶爾成為“意見領袖”。但是我發現工作中的事情需要落到實處，基本有幾點需要明確：
有想法
溝通
做事情的效率和產出
團隊協作能力
當然這個從空降或者一蹴而就來入手，顯然是阻力比較大的，除非給你的角色具有壓倒性的力量。
所以對於工作的事情，我也做了一些思考和總結，總是在想：我的目標是什麼？我現在的狀態是什麼？我現在和目標的差距有多大？問題到底出在哪裡？
經驗和建議
我做了一些提煉，有一些經驗和建議：
1無論你是否是專家，都要接觸業務
運維的意義是業務驅動，一旦脫離了業務，你會發現做很多事情會比較被動。比如你要做業務優化，但是不知道該怎麼去對接業務方；你要做出一些建設性意見，脫離了業務方的反饋，會發現計劃和反饋會有很大的出入；越脫離業務，會越糾結於很多不是問題的問題；還有一點，我覺得更加重要的是，脫離了業務，其實也是增加了代溝，你的成果他無法感知，他的痛點你也無法體會。
所以無論你是否是專家，都要接觸業務、深入業務、優化業務，縱然接觸業務會花掉不少的時間，我覺得能夠階段性地投入、有針對性地投入，還是值得的。
2你的工作量
其實我以前比較排斥工作週報，彙報工作也是階段性來做。
但是顯然，從我的角度來說，很多工作雖然做了，工作量卻很難體現，比如公司會給我安排一個里程碑的任務，同時對於運維工作，我覺得部署安裝是基礎功能，備份恢復要提前搞定，從技術發展來看，要跟進新技術預研；從業務的支持來說，業務方的需求還要盡力滿足，勢必會有一個比例的投入和優先級。
所以，如果只是按照一個核心裡程碑事件，其實我可以工作的相對很輕鬆，但是事情自己不深入來做，已有的問題還在那裡，後期要更正會更加糾結。與其這樣，不如提前發揮自己的餘熱，把這些事情先搞定。
所以我決定做一些改變，就是多承擔一些任務、多做一些事情。雖然工作確實忙了不少，但是你會發現，你解決了很多潛在問題，對自己推進工作和給同事減壓都是很好的輔助。
3工作的形式和輸出
我以前的認知中，對於形式其實不是很看重，覺得事情做好就行。換個角度來理解，我覺得這就跟大家去考取一個證書一樣，哪怕這個證書現在已經不重要了、市場上的認可價值沒那麼高了，但是你通過自學完成了系統的知識結構，同時也能夠結合工作做一些補充，那麼這就是一個實質性的工作。至於考取證書，就是一個錦上添花的狀態。
我們對於工作的形式和輸出就是這個錦上添花的補充。
有了當然更好，如果沒有其實也可以，但是如果有這麼一套考核的標準，是你的幹嘛不去爭取？如果用數據庫來打比方，就跟系統權限和角色一樣，系統權限是一些很零散的權限形式，基於對象級，太多了也沒人去關心，自己都不記得了；但是如果打包成角色，其實就有一種一目瞭然的感覺。
4你需要主動發起一些事情
磨合了很多事情，如果這個事情的結果導向不是很明確，或者大家覺得這個事情可做可不做的時候，能不能繼續做下去，就需要看一些核心的推動力了。
比如，在碰到一件事情的時候，你最好是自己主動來針對性地發起和跟進，否則這件事情很可能就是不了了之，你覺得大家應該重視，大家覺得應該由你來發起，結果出現了GAP，難免會上火和焦慮。我們的生活和工作中有太多的不了了之的事情。就好比我現在發起的自動化運維分享群，或者是要推動的一些方向性的事情。
5無腳本不歡，以手工操作為恥
我在和不同行業、角色的人聊天的過程中，發現大家對於運維的很多理解都是基礎運維。
其實，這就跟大家走一個高空棧道一樣，運維好比是兩邊的護欄，沒問題的時候看起來意義不大，但是自己走的時候發現確實很需要。說明確一些，就是工作中，儘可能腳本化、工具化、流程化來處理問題，儘可能不要手工敲命令來實現，要以手工操作為恥。
我覺得我們自身對運維的理解要上一個臺階，如果你的工作內容都是基礎運維（服務器部署安裝、環境配置、權限開通），那麼你的角色就很危險了。這種工作今天可以手工，明天可能就不需要了。
6小環境裡的大智慧
有很多同學都會說自己的公司的環境規模太小、很多方面不夠規範等問題，但是這些問題只有抱怨是解決不了的。就算你一任性，一走了之，那麼問題在其他的公司也會或多或少有類似的體現。
我要強調一點，任何級別的公司都會有大大小小的問題，絕對有很多是讓你覺得明顯不合理的細節。我建議大家不要總是抱怨，就算是抱怨，也要同時提出有建設性的意見。
有些公司，文化層面上，價值觀沒法改變，但是運維細節的改進還是很有實踐意義的。比如我舉一個具體的例子，MySQL中的Online DDL，如果你要維護管理很多版本的環境，一個500萬級別的表需要添加一個字段，那麼這個操作該怎麼做？如果你手工添加，基本也是秒級就可以完成，但是你如果再用心一些，針對不同版本，使用工具來完成，雖然看起來有些囉嗦，但就是這些細節能夠帶給你諸多經驗。一旦數據量到了千萬級別，你也有了一些基礎的經驗，你會覺得運維這個活兒是個手藝活。
7運維的幾個進階角色
對於運維的路該怎麼走的問題，方向有很多，邊界也有很多，從我的理解來說，我覺得可以有很多的進階方向。比如：
開發架構
運維應用平臺開發
應用內核開發
沒有什麼事情是那麼簡單就能完成的，這些方向可以根據自己的能力和定位來針對性地投入。現在知識更新很快，我們的理念其實也要不斷跟進、不斷更新。
看完楊建榮老師的思考和建議，大家有沒有一些豁然開朗的感覺呢？要想在工作中儘可能避免踩坑，除了這些必不可少的工作方式要落地之外，細心與耐心也是必不可少的，不然……看看本文開頭那些血與淚的遭遇，大夥兒心裡還沒點A與C之間的那個數麼？
至於禮品是什麼：
最後，祝踩坑的、沒踩坑的、順利放假的、還要加班奮鬥的各位，勞動節渡劫快樂！
閱讀更多 DBAplus社群 的文章
