过年期间新闻不少。除了动物园老虎吃人这样荒唐的事情之外，it圈里也出现了gitlab.com删库这样的重大运维安全事故。

事故的起因是gitlab的运维在处理线上故障的过程中，可能是有点疲惫了，本想删掉一个从库，重新从主库复制一遍，结果眼睛一花在主库上敲了“rm -rf / ”。虽然两秒钟后他就意识到不对了，但是悔之晚矣。

删库这样的事故其实很常见，我当年也干过这样的蠢事。俗话说得好，常在河边走，哪能不湿鞋。只要是靠人来做手动的操作，那么迟早会出现问题的，毕竟人总有犯错误的时候。就像小时候考试，我每次都检查好几遍，但总是很难拿到100分。

那么怎么解决这样的问题呢？有几种思路。一种是加强管理，从流程上杜绝犯错误的可能性。譬如在线上执行任何操作的时候，都必须由两个人来完成，一个人敲命令，另一个在边上看着负责检查。这样犯错误的可能性就大大降低了。但这样做不好的地方是成本增加了，原来一个人能干的活现在得几个人才能完成。本来IT强调的是自动化，靠堆人肉来干活有点开倒车的意思。并且是人就会犯错误，几个人一起犯错误的情况也很常见，特别是大家互相比较信任的时候。

另一种思路就是备份。依靠备份的恢复来解决之前犯错误的问题。这听着是挺靠谱，但问题在于备份的实时性如何保证。比较好的办法是每天做全量备份，当天的修改用日志的方式做增量备份。这样想恢复到哪个时间点都问题不大，只是还要解决恢复速度的问题。

我觉得最好的思路还是从根本上减少犯错误的可能性，那就是减少人的操作，尽量用机器自动化的方式去解决问题。这就是基础设施即代码，也就是把原来手工的操作都通过脚本来进行，以代码的形式维护起来。把对生产环境的任何操作，都看作一次发布的过程。这样从代码上就知道你做的是什么操作。相反，如果依靠在线上敲命令来做运维的话，没人知道你下一步会敲出什么荒唐的命令来，比如rm -rf / 。

基础设施即代码听起来不错，但也需要团队投入很大的精力在这上面，得先把这样的基础设施建立起来。有一些工具可以帮助团队实现这一点，比如chef，puppet这样的自动化配置管理工具。

我自己也很缺乏这方面的经验，有机会逐步改进吧。