1、历史回顾：20150528携程运维??事故。2015年5月28日上午11点开始，携程网官网突然出现404错误页面。app也不可用，业务完全中断。据称，五云网公布了携程的一个漏洞，“携程网服务器配置不当可导致官方邮箱被劫持”。它无法发布，并且（包括代码的根目录）一发布就被（物理上）删除了。”虽然数据库还在，但是应用已经被删除，业务很长时间都无法恢复。当天下午，携程曾一度切断对艺龙的流量，但艺龙无法承受，雪崩关闭。当晚19点左右，停机8小时后，携程手机APP率先恢复，但订单提交依然不稳定。当晚22时45分，携程的服务全面恢复。至此，该服务已暂停整整12个小时。第二，携程出事后我们做了什么，落实了什么？当时我提出在业务连续性计划（BCP，BusinessContinuityPlan）之外尽快实施灾难恢复计划（DRP，DisasterRecoveryPlan）。DCP的目标是：当IDC机房无法物理连通时，可以快速异地重构生产系统。分为两个层次：代码和配置的容灾；数据的灾难恢复能力。如今，DCP的目标已经通过以下方式间接实现：代码和配置的容灾：Docker镜像：Web容器配置都在Docker容器镜像中；机房各处都有自动同步的镜像库；异地双活机制，即Nginx/DNS等服务配置信息异地备份；CloudEngine（我们的研发协作平台）保存了各个项目在不同环境下的应用属性（也是配置信息）；数据容灾：异地备份：借助iDB（我们的数据库自动化运行和主动??机制，相当于说全库异地同步。3.20190120拼多多无门槛优惠券大事件来自1：2019年1月20日00点至10点，羊毛党员狂欢9个小时，收到（而非抢购）拼多多100元无门槛优惠券，据信拼多多损失数千万元。据传，这张无门槛优惠券其实对应的是一次过期操作，但由于操作失误，在凌晨重新上线。p.s.：优惠券来源：〃在官方公告中拼多多，需要说明的是，这张优惠券是拼多多此前与江苏卫视《非诚勿扰》合作时因节目录制需要而生成的特殊优惠券，仅限现场嘉宾使用。另外，这种类型的c优惠券从未以任何时间、任何方式出现在平台正常的网络推广活动中，甚至从未有过任何网络入口。〃四、拼多多事故对我们的启示，以及我们应该做的操作规则、技术保护、风险控制和预警、法律规定，电商行走江湖的四大法宝是必不可少。万一出事不可怕，怕的是没有人知道发生了什么。如果不是当天早上出现并发异常，拼多多技术团队也不会发现这么多优惠券被抢走了。风控体系的建立很关键：我们已经推出了业务保障平台和全链路跟踪，可以实时监控第三方支付渠道的活动，并及时预警。但这还不够。建立交易自动化监控机制和风险监控模型，实时监控预警；通过分析欺诈行为的特征，制定反欺诈规则，对交易数据进行实时分析；应制定异常交易监控和处理的流程和制度；识别确认风险数据，建立黑名单数据库；...每个电子商务公司在规则和程序上都有漏洞。风控系统包括对传统业务指标的监控和告警，至少可以让我们发现系统潜在的漏洞并及时修复，而不是一个人知道系统出了问题。我们应该把别人的历史当成自己的未来，这样我们才能知道他们过去哪里做错了，现在我们应该怎么做。献上另一篇旧文，也是携程出事后写的。携程的技术团队今天注定要失眠了。我的猜测是，自动化运维系统太强大了，不会被误操作淹没。此外，它历史悠久，规模宏大。各种新旧系统相互交织，全面重新部署、迭代上线。肯定不一样，难度更高。这就是为什么过去我反复强调审计对我们这些年做的内部安全审计非常重要。对他们提出的意见，要认真研究和落实。为提醒各位技术人员，现将此次携程误操作事件引发的各种滑溜投诉一览表。Rebuild：Coolshell在Amazon的时候，一个AWS的新人，第一天上班就在做开发环境的自助培训。他想连接到测试环境，但是连接不上。老员工给了他一个配置，但是他没有分清哪一个是测试的，哪个是生产的，不小心连上了产线数据库，把整个数据库都给Rebuild了，导致Netflix停止服务了几个小时;Recreate：有人用hibernate逆向生成了数据库的一张表，并且连接了test库，但是没有加配置，格式化所有的表，重新创建。UPDATE没有WHERE条件：十一年前有人手写SQLUPDATE在线数据库，因为引号截断了WHERE子句，几乎清空了用户原来的所有内容，不幸的是，运维也出错了，备份程序停了半个月，于是全公司的同事手动从搜索引擎快照中检索用户的文章。之前更新错了数据，手滑了。where条件我还没写完呢。我想移动鼠标，但点击执行。我一次性把所有的采购订单数据都改了一定量，然后dba立马恢复了我操作前的数据。短短三五分钟，客服端就接到了很多投诉电话。错误配置：有一次在做带宽调度算法时，方向写错了，瞬间给了一个CDN提供商100G左右的带宽，持续了16个小时。给公司造成了近20万的带宽成本。有人迄今为止最昂贵的错误。DiggingYourOwnHole：有人曾经摧毁了整个服务器。事情是这样的，有一个硬盘是镜像备份，挂载的是sda1之类的名字，而不是uuid。后来加了一块硬盘，原来的数据盘变成了sda1，意思是从一个空盘做镜像。刚加入高盛的时候，不小心把生产环境的合规数据库给锁了，纽约gsam的股权交易停了15分钟。经理说没关系，我惹的麻烦更大了。我胆子太大了。我几年前才开始学习如何管理Windows服务器，并禁用了几个Windows服务。导致部分服务相互依赖无法启动，停机长达数十小时。不知道怎么说了：某年，研发部的电脑硬盘全部被盗，95%+的产品源代码丢失。为了维护一个已经上线的产品，使用了HttpHandler来处理。客户为了重新部署系统，将数据导出备份到移动硬盘，然后重新格式化Raid，重装系统。重建Oracle数据库导入数据时，发现无法正确读取移动硬盘上的数据，并且有一半的文件丢失。.曾经在catch中写过system.exit。drop遍历生产环境数据库表。刚入行的时候，在代码里加了systemrm，然后测试环境下的大部分程序都不见了。我天真地以为这是黑客干的。以前把图片的地址写成“undefined”，上线后以为ddos了。
