GD 数据流项目之踩坑

1. 把工作成果以及一些script都保存在公司的linux服务器的个人工作目录下，一个周末在清理冗余文件的时候，

   不慎把服务器上的个人目录rm -rf *

2. 有一个shell脚本需要从正式网向测试环境导数据，在踩完坑1.后，这个脚本自然也被rm了，连夜重写了一份。

    这个脚本中有一个逻辑：

    导入数据前，先要清掉测试环境数据库的数据。

    结果，夜间作战时，copy数据的时候，把脚本中的ip写错了，导致脚本的逻辑变成了，导数据前，清除正式网的数据。

    然后，10.19号下午4点30左右，一执行脚本，看到log中的ip貌似是正式网的，立马傻眼了，穿着短袖的手臂上，冷汗蹭蹭的冒，赶紧停掉命令。

    一查正式网的数据，发现数据量级并没有异常，然后拍拍胸脯，长吁一口气，跟自己说，还好，还好，吓死我了，然后松了一口气就没管这事了。

    等到晚上7：30左右，负责这个项目的RD突然问我有没有动线上数据，我一惊，暗知不好。

    赶紧再查数据库的量，几乎为0了~~几乎为0了~~

    正式网的数据~~正式网的数据~~

    我抱着必死的心态赶紧捧着电脑去找RD，交代事实，并着手解决问题。

    第一步：观察数据量没有持续减少了，说明删除命令的后遗症已经over。

    第二步：确认服务正常，确保增量数据能正常入库。

    第三步：联系DBA，确认数据能否恢复，由于数据量太大，几千万+、400G，DBA反馈恢复时间耗时较长。

    第四步：跟本项目的PM、RD负责人商量具体解决方案。

    最终达成共识：保证服务正常，让增量数据正常入库，历史数据慢慢恢复。

    

    结果：所有数据在第二天下午3:30全部恢复，其中两个量级较小的表（1000w+）是DBA从日志历史中恢复，

    另外一个大表（3000w左右）我之前每天做离线数据分析时，有备份。

    并在下午6点发起了事故复盘。    

这个事故是一个连环失误，我做了如下总结，以戒下次。

1. 事前：在服务器上进行的危险操作，对正式网数据的操作，要慎之又慎。

2. 事中：出现问题之侯，要及时暴露，跟相应的RD、Leader确认，不能仅凭自己的判断认定疑似危险操作的后果。

3. 流程：线上（特别是用户量级比较大时）数据，以及服务，要做好容灾处理。

    服务：性能、异常处理。

    数据：定时备份。

4. 做事方法：

      4.1 代码要定时提交代码仓库。

      4.2 脚本要定期备份。

      4.3 执行危险脚本、命令时，要多确认，最好有提示。