报警千万条，重点只一条

运维不规范，加班两行泪

运维事故一

事件回顾

在某个周六下午，数据库由于供电意外中断的原因而产生故障，导致数据损坏。

工程师们来不及反思数据损坏发生的原因，第一时间着手进行抢修——重启数据库并且尝试数据恢复。看起来问题应该很快就能够解决,但不幸的是，有小部分数据并没有备份，导致服务中断，企业损失较大。最终不得不通过数据归档。

事件反思

数据的备份永远只为了那1%的可能性：手里有粮，干活不慌。

• 日常备份

须设置自动快照策略，关联每块磁盘。

• 操作前备份

重要系统变更、应用更新等，需要提前做好快照。

文件变更，需要提前做好文件目录拷贝备份。

数据库变更，一定要做好数据库的备份。

运维事故二

事件回顾

一个阳光明媚的早上，在生产环境一顿操作，导致某业务服务器的应用目录被删。万幸的是由于业务采用集群，没有对业务造成影响

事故原因：

find | xargs 删除日志的路径写相对路径，执行后已经解决问题了，但是运维工程师退回到上一级目录后，后使用历史命令执行了一次find | xargs命令，导致应用目录被删除。

事故反思

永远不要在线上环境做测试

90%运维事故都是由于变更导致

任何测试/调试都不要在线上环境操作，这可能会导致严重的灾难事故。

测试/调试均放在测试环境。

性能消耗大的操作在业务低谷时操作。

变更前需备份，需要快照备份系统盘或数据盘。

运维事故三

事件回顾

某天，接到报警短信，告知磁盘使用率大于80%，因此就想清理掉log 日志，结果直接执行了 rm -rf /var/* ，看到报警恢复后，就愉快地玩耍去了

关于rm -rf /var 这种错误，手快的人，或者网速比较慢的时候，出现的几率相当大。一不小心，后半生就搭进去了

事件反思

ENTER前再三确认

永远不要以为那些运维事故都是在别人身上，如果你不注意，下一个就是你。

find匹配查找删除，每次先打印匹配结果，结果无误在删除。

删除操作用绝对路径。

运维自我修养

首先，每一次操作，都要有意识追求稳定性和安全性。

其次，每一次操作，都要有意识追求效率。

如若在重复的做某些事情，即一个事项我们重复做第二遍和第三遍的时候，我们要思考这样的事情能不能通过什么方式提升效率、或者能不能自动化掉。如果运维是一个太无聊的循环，那人生又有什么意义和价值。