中国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.:

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

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

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

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

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

• 我们已经上了业务保障平台和全链路追踪，能够实时监控第三方支付通道的活动，及时预警。但这还远远不够。

• 应建立自动化的交易监控机制和风险监控模型，实时监控，及时预警；

• 应通过分析欺诈行为特征创建反欺诈规则，对交易数据实时分析；

• 应制定异常交易监测和处理的流程和制度；

• 应依据已识别并确认的风险数据，建立黑名单数据库；

• ……

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

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

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

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

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

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

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

• Rebuild：

  • 当年酷壳在亚马逊的时候，AWS的一个新人在工作第一天做熟悉开发环境自助培训时，他本来想连测试环境，结果连不上，老员工给了他一个配置，他没分清哪个是测试的，哪个是生产的，不小心联上了生产线数据库，把整个数据库给 Rebuild 了，导致全美 Netflix 停止服务数小时；

• Recreate：

  • 某人用 hibernate 反向生成数据库的一张表，并且连的是测试库，结果一个配置没加，把所有的表都格式化掉并重新创建了一次。

• UPDATE没有WHERE条件：

  • 十一年前，某人手写 SQL UPDATE 线上数据库，由于引号把 WHERE 子句截断，用户原创内容几乎全都被清空，不幸的是运维也出错了，备份程序停了半个月，于是全公司同事手工到搜索引擎快照中找回用户的文章。

  • 以前更新错误数据，结果手滑 where 条件还没写完呢，想动一下鼠标，结果点到执行。一下子把所有的采购单数据的某个金额给改了，后来 dba 立刻恢复我操作以前的数据，就这三五分钟的时间，客服那边就接到了超多投诉电话。

• 配错了：

  • 有次做带宽调度算法，方向写错了，瞬间给一个 CDN 提供商搞了 100G 上下的带宽，持续 16 小时。给公司造成了近 20 万的带宽费用。某人至今最贵的bug。

• 自己挖坑：

  • 某人曾把整个服务器全部抹掉了。事情是这样的，有一个硬盘是镜像备份，挂载的时候用 sda1 这样的名字，没有用 uuid。后来加了个硬盘，结果原来的数据盘成了 sda1，等于说从一个空盘做镜像。

  • 在高盛刚入职的时候一不小心把生产环境 compliance 数据库锁了，纽约 gsam 的 equity trading 停顿了15分钟，完了经理跟我说，没事儿，我闯过更大的祸。

• 胆子太大

  • 好几年前刚开始学着做 windows 服务器管理，把几个 windows 服务禁用，结果造成有服务互相依赖启动不了，停机几十个小时。

• 已然不知道该怎么说了：

  • 某年研发部所有电脑硬盘被偷，95%+的产品都丢了源代码，为了维护一个已经上线的产品不得已，挂 HttpHandler 来处理。

  • 某客户为了重新部署系统，将数据导出备份到移动硬盘，然后将 Raid 重新格式化，重新安装系统，当进行 Oracle 数据库重建，导入数据时发现，移动硬盘上的数据无法正确读取，文件缺失一半。

  • 曾经在 catch 里写过 system.exit。

  • drop 过生产环境数据库表的路过。

  • 刚入行时曾在代码里加过 system rm，然后测试环境里的大部分程序都失踪了，天真的以为是黑客干的。

  • 曾经把图片的地址都写成了“undefined”，上线后以为被 ddos 了。

（编辑：ASP站长网）