没有遇到故障的运维不是合格的运维，没有处理故障的运维不是好运维。
做运维这么多年，每天依然提心吊胆，担心突发故障，打破生活节奏。
可是，人算不如天算，**大部分故障都来源于近乎合理的操作**，这次也是一样。
起因是要把几百 G 的数据传输到阿里云的 Nas，通过外网挂载的方式拷贝。按道理讲这没什么问题，不就几百 G 的数据么，之前拷贝几个 T 的数据都没问题。
可偏偏不按道理讲。
这几百 G 的数据全是由大量的小文件组成，在拷贝的时候既要频繁的占用本地磁盘 IO，也要占用网络 IO，然后事情就发生了——服务器的负载直接干爆（原本 8 核的 CPU，负载高达 500 多），而且服务器是老年机，配置很 Low。这就导致该服务器直接处于死亡状态，更可气的是该服务器是 K8S 集群的 master，Master 宕机，其他节点失联，集群处于崩溃中。
负载下不来，服务器无法操作。只有出绝招了——重启服务器。
在提心吊胆中服务器终于是起来了。但是，新问题来了，Docker 起不来，提示 /var/lib/docker/overlays Input/Output error。
这特么不是尽给我惹事么，所幸的是只是这个目录下的部分文件异常，整个文件系统并没有损坏。
既然你起不来，那我就换一个目录吧，我就在 /etc/docker/daemon.json 中重新更改了目录：
cat > /etc/docker/daemon.json << EOF
{
"data-root": "/data/docker"
}
EOF
Docker 起来了，看似向好的方向发展了，可是 Docker 压根用不了。
陷入了沉默，内心焦躁不安，如果不及时解决会影响整体的项目进度…
开始做最坏的打算——重做。随机开始把未备份的数据进行备份 ，然后另一方面问谷歌大佬，看有没有类似的问题，最后什么也没找到。
沉入谷底，如果重做，我一晚上都不一定能做好，但是不重做，所有的工作都可能停滞。
为了静下心，买了一盒泡面…
其实问题的目标很明确了，修复好 docker，一切都迎刃而解。
又重头去梳理 Docker 的配置。发现 Docker 的启动文件中有引入其他配置。
然后发现在 docker-options.conf 中有配置 Docker 的 data-root，我就把其改了，把原来 /etc/docker/daemon.json 删了。
神奇的事情发生，Docker 能够正常启动，也没有再报任何错误。
现在就开始启动 Etcd，为了保险起见，将原有的数据进行了备份，然后重新恢复故障前最近的 Etcd 备份文件。
Etcd 顺利起来了，然后 apiserver、controller-manager 等都起来了，整个集群开始正常运转。
**问题发生的出乎意料，问题解决的也出乎意料。**
所以，平时在工作中：
1、做好备份
2、谨慎操作
3、冷静分析
问题发生，总要找解决办法，做好最坏的打算。在解决问题的过程中一定要冷静，我有一阵子很急躁，导致没有仔细去看配置，所以延缓了恢复时间。