沒有遇到故障的運維不是合格的運維，沒有處理故障的運維不是好運維。

做運維這么多年，每天依然提心吊膽，擔(dān)心突發(fā)故障，打破生活節(jié)奏。

可是，人算不如天算，大部分故障都來源于近乎合理的操作，這次也是一樣。

起因是要把幾百G的數(shù)據(jù)傳輸?shù)桨⒗镌频腘as，通過外網(wǎng)掛載的方式拷貝。按道理講這沒什么問題，不就幾百G的數(shù)據(jù)么，之前拷貝幾個T的數(shù)據(jù)都沒問題。

可偏偏不按道理講。

這幾百G的數(shù)據(jù)全是由大量的小文件組成，在拷貝的時候既要頻繁的占用本地磁盤IO，也要占用網(wǎng)絡(luò)IO，然后事情就發(fā)生了——服務(wù)器的負(fù)載直接干爆（原本8核的CPU，負(fù)載高達(dá)500多），而且服務(wù)器是老年機(jī)，配置很Low。這就導(dǎo)致該服務(wù)器直接處于死亡狀態(tài)，更可氣的是該服務(wù)器是K8S集群的master，Master宕機(jī)，其他節(jié)點失聯(lián)，集群處于崩潰中。

負(fù)載下不來，服務(wù)器無法操作。只有出絕招了——重啟服務(wù)器。

在提心吊膽中服務(wù)器終于是起來了。但是，新問題來了，Docker起不來，提示/var/lib/docker/overlays Input/Output error。

這特么不是盡給我惹事么，所幸的是只是這個目錄下的部分文件異常，整個文件系統(tǒng)并沒有損壞。

既然你起不來，那我就換一個目錄吧，我就在/etc/docker/daemon.json中重新更改了目錄：

cat > /etc/docker/daemon.json  << EOF
{
    "data-root": "/data/docker"
}
EOF

Docker起來了，看似向好的方向發(fā)展了，可是Docker壓根用不了。

陷入了沉默，內(nèi)心焦躁不安，如果不及時解決會影響整體的項目進(jìn)度......

開始做最壞的打算——重做。隨機(jī)開始把未備份的數(shù)據(jù)進(jìn)行備份 ，然后另一方面問谷歌大佬，看有沒有類似的問題，最后什么也沒找到。

沉入谷底，如果重做，我一晚上都不一定能做好，但是不重做，所有的工作都可能停滯。

為了靜下心，買了一盒泡面.....

其實問題的目標(biāo)很明確了，修復(fù)好docker，一切都迎刃而解。

又重頭去梳理Docker的配置。發(fā)現(xiàn)Docker的啟動文件中有引入其他配置。

然后發(fā)現(xiàn)在docker-options.conf中有配置Docker的data-root，我就把其改了，把原來/etc/docker/daemon.json刪了。

神奇的事情發(fā)生，Docker能夠正常啟動，也沒有再報任何錯誤。

現(xiàn)在就開始啟動Etcd，為了保險起見，將原有的數(shù)據(jù)進(jìn)行了備份，然后重新恢復(fù)故障前最近的Etcd備份文件。

Etcd順利起來了，然后apiserver、controller-manager等都起來了，整個集群開始正常運轉(zhuǎn)。

問題發(fā)生的出乎意料，問題解決的也出乎意料。

所以，平時在工作中：

1、做好備份

2、謹(jǐn)慎操作

3、冷靜分析

問題發(fā)生，總要找解決辦法，做好最壞的打算。在解決問題的過程中一定要冷靜，我有一陣子很急躁，導(dǎo)致沒有仔細(xì)去看配置，所以延緩了恢復(fù)時間。