中国IT史上两大严重事故对我们的警醒及预防措施

中国IT史上两大严重事故对我们的警醒及预防措施

一，历史回顾：20150528携

程

运

维大事故

2015年5月28日上午11点开始，携程旅行网官方网站突然显示404错误页，App也无法使用，业务彻底中断。

据称是因为乌云网公布了携程的一个漏洞“携程旅游网服务器配置不当可导致官方邮件劫持”，携程修复后当天准备上线发布，但运维自动化系统有问题或者运维操作有问题，导致“发布不上去了，刚发就（根目录包括代码）被（物理）删”，虽然数据库还在，但应用都被删了，业务迟迟无法恢复。

当日下午，携程一度将流量切给了艺龙，但艺龙承受不了而雪崩宕机。

当晚19时许，离宕机过去8个小时后，携程旅行网手机APP首先恢复，但是提交订单仍然不稳定。

当晚22:45，携程服务全面恢复，至此，停服整整12个小时。

二，携程事故之后我们做了什么，最后落实了什么

当时我提出在Business Continuity Plan（BCP，业务持续计划）之外尽快落实Disaster Recovery Plan（DRP，灾难恢复计划）。

DCP的目标是：

当IDC机房物理无法连接时，可快速异地重建生产系统。

它分为两个层级：

代码和配置的灾难可恢复性；数据的灾难可恢复性。

时至今日其实通过以下做法间接达到了DCP的目标：

代码和配置的灾难可恢复性：Docker镜像：Web容器的配置都在Docker容器镜像里；私有分布式镜像仓库，能够做到在混合云多机房各处都有自动同步的镜像库；异地双活机制等于说异地备份了Nginx/DNS等服务配置信息；CloudEngine（我们的研发协作平台）里保存了各种工程在不同环境里的应用属性（也是配置信息）；数据的灾难可恢复性：异地备份：在iDB（我们的数据库自动化运维平台）的帮助下有数据库自动备份以及备份的可恢复性自动检查，并且做了异地备份；异地双活机制等于说异地同步了全量数据库。

三，20190120拼多多无门槛优惠券大事故

2019年1月20日凌晨1点到10点，整整9个小时，羊毛党徒们狂欢，从拼多多领取（而不是抢购）100元无门槛优惠券，据信拼多多损失高达数千万元。

据传，这个无门槛优惠券实际上对应于已过期的运营活动，但由于操作失误，导致凌晨又重新上线。

p.s.:

劵的来历：〃在拼多多官方的公告中指出此券为拼多多此前与江苏卫视《非诚勿扰》开展合作时，因节目录制需要特殊生成的优惠券类型，仅供现场嘉宾使用。除此之外，此种类型优惠券，从未在任何时候、以任何方式出现在平台正常的线上促销活动当中，甚至从未有任何线上入口。〃

四，拼多多事故对我们的启示，以及我们要做什么

运营规则，技术防护，风控预警，法律条款，电商行走江湖的四大护身法宝，缺一不可。

出了事儿不可怕，怕的是都没有人知道出事儿了。要不是当天上午有并发异常，拼多多技术团队也不会顺藤摸瓜发现被领走那么多券。

风控体系的建立，至关重要：

我们已经上了业务保障平台和全链路追踪，能够实时监控第三方支付通道的活动，及时预警。但这还远远不够。应建立自动化的交易监控机制和风险监控模型，实时监控，及时预警；应通过分析欺诈行为特征创建反欺诈规则，对交易数据实时分析；应制定异常交易监测和处理的流程和制度；应依据已识别并确认的风险数据，建立黑名单数据库；……

每个电商都有规则漏洞，都有程序漏洞，无非是在多大范围内被黑产和赚客们薅羊毛。

风控体系包括对传统业务指标的监测和报警，至少能让我们发现系统潜在的漏洞，及时修补，而不是最后一个知道系统出事儿的人。

我们要把别人的历史当作自己的未来，这样才能知道过去人家错在哪里，我们现在应该怎么做。

再赠送旧文一篇，也是携程事故之后写的。

携程旅行网的技术团队今天注定是一个不眠之夜，我的猜测是自动化运维系统过于强大以至于误操作后覆水难收，加之历史悠久规模庞大各种新老系统交错，全面从新部署与平常迭代上线肯定不一样，难度系数更高。

这也就是为什么过去我反复强调审计历年来对我们做的企业内部安全审计非常重要，他们提出的意见，我们必须认真审视认真去落实。

为了警醒各位技术人员，下面列出本次携程误操作事件引发的各种手滑吐槽。