《那些刻骨銘心的誤操作，我們到底該如何避免呢？》要點：
本文介紹了那些刻骨銘心的誤操作，我們到底該如何避免呢？，希望對您有用。如果有疑問，可以聯系我們。

我最近在網上逛CSDN論壇“Linux系統管理”版塊時,看到一篇發布于2008年標題為《寫下你職業生涯中最難以忘懷的誤操作》的帖子,該帖子截止本文寫作時共有664條回復,在論壇里除了簽到、踢樓、灌水貼之類的主題,能達到這個參與度可見該話題確實引起了大家的共鳴,雖然我在另外一篇文章中整理過幾條危險可致命的誤操作,但看了這個帖子里的文章后會發現他們的誤操作是如此的相似.

我先說下自己的一次經歷：曾經通過桌面共享的方式登陸到客戶生產環境協助現場工程師解決某個功能不正常的問題(注意：僅僅是某個功能,軟件狀態還是RUNNING的),由于通過查看日志暫時分析不出原因,又急于恢復環境,就憑借經驗直接對該軟件執行了restart的操作,結果是我的經驗判斷是準確的,功能確實恢復正常了.但現場傳來一句話“這是生產環境,有客戶正在使用的,你這個restart是什么意思?有什么影響?”,當時愣住了,還好這個軟件并不影響主要業務...所以,從那以后所有涉及業務重啟的操作,都需要先征求現場的同意,不要把開發環境的作風帶到生產環境.

下面我摘錄了一些“精彩的”誤操作,這其中是存在一些共性的,也是可以通過端正我們的操作習慣來避免的.
如果你也有過刻骨銘心的誤操作,不妨和大家一起“分享”下...

marsaber:

我……
沒完全關閉計算機,我拔光驅,把主板給燒了.

skylove:
ghost用得太多...有次在備份資料的時候,想偷懶用ghost搞定 (win平臺,非熱備份)...結果...結果...兩塊硬盤太象了..

C.J:

編了兩天兩夜的 linux (第一次lfs), 做了個tar后, 刪除原來的文件,發現tar解開出錯...

xcrossbow:

07年底,想把一個img寫到優盤時,用了如下糟糕的命令
dd if=./xxx.img of=/dev/sda
由于一直記得我的Thinkpad T43是并口硬盤,因該識別為 hda,自以為第一個優盤是sda了,打完后重啟才意識到問題!
幸虧了解并用過sysrecue盤,參考以前看的linux server hack 2中的使用gpart恢復分區一節,找到了數據分區,救出了數據,好懸!

itxiaofei:

刪除某變量路徑下的目錄,結果此變量為空
rm -rf $abc 實際就變成了 rm -rf /
從這以后,rm要帶r都必須先確認目錄,變量都必須判斷一次

sanyork:

前年夏天管一個小的機房,機房里面有四個機架二十多臺服務器,安裝了兩個空調,一個1.5匹的和一個5匹的,白天上班機房有中央空調,為了省電,白天只開1.5匹的,下班的時候忘記了開那個5匹的空調,結果1.5匹的那個空調由于負荷太大罷工了,后來機房里所有的服務器全部死機了,打開機房,里面溫度有六十多度,不過那些IBM的服務器硬件質量還不錯,所有的機器都發出報警聲,沒有造成硬件損壞,重新啟動后就好了.

linxor:

可是不知道怎么的,那次要刪除目錄下的所有內容,本來要執行rm -rf ./*,卻少輸入了一個點,成了rm -rf /* 后果你是知道的!再也起不來了,連reboot都沒有了,只有reset了!

Dalamar:

經常在十幾臺機器之間來回切換,有次rm -rf ./* 清個文件夾,結果執行完發現rm到其他機器上去了….
從此以后執行重要命令之前先ifconfig看下ip

feiwupiaoxue:

02年底剛到公司不久,給一位人事的漂亮妹妹重新安裝win98,我用Ghost,結果人家安裝了兩個系統,我沒有注意,一下子把系統文件等等都搞沒有了,結果我圓了個慌,說系統壞了,文件也丟失了,我給她裝好了.結果她謝了我,還請我米西一頓,成了我第一個女朋友,大半年后我們分了.一切不是我的錯,嗚嗚!：(

—注：我認為這小子是故意的~

hustwk:

有一天心血來潮,想把windows里的NTFS轉換成為FAT32格式的.用魔法兔子的轉換工具,警告說此功能尚不成熟,不保證能夠轉換成功.當時也沒想就確認了,結果我的兩個分區(特別是最后一個分區是備份數據的),全沒了.搞了幾天都無法恢復,積累了三年的資料毀于一旦,寫了十幾萬字的自傳也over了,哭啊哭啊,崩潰

tech_linux:

工作第一年,刪除數據庫表內數據. where條件后是ID=, 結果刪到最后一個時走神, 沒寫id=,直接寫了個數. 三秒鐘,七百多萬條數據被我刪了. 當時全腦空白,后聽同事說我臉色慘白!! 恢復一夜,還是丟失部分數據, 關鍵服務,核心數據庫

ssffzz1:

大家還記得以前的昆騰大叫硬盤吧!
有一次修電腦,把硬盤的電路板朝上了.和一個同事在說話,沒想到一個唾沫星子,掉線路板上,當時就冒煙了,趕緊斷電.一看好像是一個元件都糊了.可是通電后,硬盤居然沒事.
至今我也想不明白,元件都糊了,硬盤為啥沒事.

linux小小白:

印象比較深的兩次：一次在linux下,本來是ls某個目錄,看到了該目錄里的東西,那時想把里面全刪掉(沒用了),結果我以為是cd進去了,最后 #rm -rf * 半分鐘后發現不對勁,ctrl+C,還是晚了,因為我是在/下,還好到時是在實驗環境..還有次在windows,想在PE里重裝下C盤,結果選錯選項(from disk和from partition)最后整個硬盤被覆蓋了,還好當時備份了分區表…

pp12416:

生產系統,為了測試冷備機,圖省事,就直接把原來兩臺主服務器的網線拔掉了,沒想到當時主服務器上面的集群馬上就全部掉線了,當時嚇得....
還好重啟后就恢復了,這事雖然沒有造成什么影響,因為是很重要的生產系統,所以還是給我留下了很深刻的印象.
在此也提醒下各位同行,根據本人的經驗,不論是windows還是linux,只要是帶集群的系統,千萬不要隨意拔服務器的網線,因為基本上所有的集群資源都是監聽IP的,如果網卡down了,結果可想而知.

feiyang1002:

親歷的事：一個同事執行tar任務,沒有觀察文件夾的大小直接執行tar 結果導致服務器馬上宕機,事后查看該文件夾有20多G,當時負責服務器的同事臉色大變,主要是還是生產系統.,無數客戶在訪問.最后重啟解決.

wonderone:

live的系統,history | grep reboot ,忘記輸入grep了...

看完上面這些誤操作后,你有何感想,是否和你曾經的經歷非常的相似...寫這篇文章不是為了笑話這些家伙,而是為了對這些案例進行總結提煉,以“負向改進”的方式來提升我們的經驗,這些案例總結主要是下面兩點值得我們牢記于心的：
1. 如果是生產環境,那么你的操作必須仔細,不要以為自己的技術牛,按照習慣性操作去處理.
2. 凡是涉及到破壞數據的操作(rm/dd/格式化之類),必須確認路徑是否正確.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4679.html