2019年IT事故盘点【IT必读】

昀哥@老兵笔记

2020农历新年开局不容易，新冠肺炎仍在攻艰克难阶段。回首过去的9102年，总有一些事主要是事故值得去记录。下面我们来盘点一下9102年的“外部事故”。

 

一，我们遭遇的IT基础设施服务事故

2019年是IT基础设施服务相对黑暗的一年。各种灾难性事件高发，我们所依赖的多家公司的关键服务不可用时间突破SLA四个九（即一年52分钟）。下面我们回顾一下：

1. 阿里云：2019年3月3日，凌晨0点开始，阿里云华北二机房可用区C部分ECS服务器等实例出现IO HANG，导致托管业务的所有服务器资源使用率100%且均无法登录，业务中断长达3小时。

2. 中国移动：2019年3月15日，由于中国移动的物联网集中化系统（CMIOT）凌晨部署架构优化（第二批）割接上线，从7点11分开始影响全国大面积物联网卡使用，于7点30分开始逐步恢复服务，但由于数千万张物联网卡排队接入，直至上午11点才缓解。

3. 银联、网联和微信支付：2019年3月23日，14点42分左右，银联和网联（两个清算机构）与微信支付上海机房的物理连接被挖断了，虽然他们快速切换了备用线路，但下游业务均受到了影响，所有交易（支付宝、微信支付、云闪付）都在抖。

4. 114DNS：2019年4月4日，10：30～12：30，114 DNS和谷歌DNS 8.8.8.8 相继挂了。

5. 上海移动：2019年5月29日，11：10～11：20，上海移动网络出现异常，网络和通话均受到影响，上海地区一度无法线下收单。

6. 支付宝：2019年12月5日，16：23～16：45，支付宝出现全网故障，系统报错“010002：系统异常”陡增，历时22分钟。全网均有感知，新闻报道“支付宝崩了”。

7. 阿里云：2019年12月6日，部分用户反馈阿里云华北、华东地域部分网络出现异常，影响部分云资源访问。

 

二，IT大厂事故

每年IT大厂都会飞出各种妖蛾子，下面我们盘点一下2019年到2020年春节前的IT大事故：

1. MongoDB：2019年1月，网络安全人员Bob Diachenko在推特上爆料，深网视界的MongoDB数据库在公网上“裸奔”，允许完全访问，全球新闻界随后大举跟进了这起大规模数据泄露事件，该数据库包含256万条以上的个人信息记录，涉及身份证号码、签发和到期的时间、性别、国家、地址、生日、护照照片、雇主以及基于摄像头所记录的过去24小时内经过的地点信息，约668万条记录。

2. 拼多多：2019年1月20日，拼多多一个100元无门槛优惠券（对应于一个已过期的运营活动）由于操作失误，导致凌晨又重新上线，从凌晨1点到10点，整整9个小时，羊毛党徒们狂欢，据信拼多多损失高达数千万元。

3. Facebook：2019年3月22日，据匿名内部员工透露，从2012年至今，有将近2～6亿Facebook用户的账户密码可能是以纯文本形式存储的（即明文存储），并且可被2万多名Facebook员工搜索。

4. AWS：2019年3月22日，前AWS网络工程师Thompson利用AWS的“配置漏洞”或“防火墙设置错误”，入侵了AWS客户美国第一资本银行（Capital One Financial）的S3 Bucket（存储桶）并下载了其中的内容，她还尝试利用 IPredator 的 VPN 和 Tor 来隐藏入侵痕迹。她将数据发布在其Github账号内，并在推特上吹嘘她持有这些客户隐私数据。

5. AWS：2019年10月22日，亚马逊的AWS DNS 服务器遭遇猛烈而持久的 DDoS 攻击，攻击持续了15个小时！

6. ES：2019年12月，还是Bob Diachenko宣布发现了一个巨大的、可公开无密码访问的ElasticSearch数据库，包含超过27亿个电邮地址，其中有10亿个的密码都是简单的明文存储，这种情况很像是原本买下了该数据库的某人本试图启动其搜索功能，却被错误配置成了公开可用。

7. 京东：2020年1月8日，估计是误操作把京东自营小家电品类上到了200元无门槛券的适用区域里，时间长达五十分钟，据信涉及24万笔低价订单，预估商品金额7000万。

 

三，我们遭遇的各种外部软件缺陷事故

常在河边走，难免会湿鞋，用第三方软件用的久了，也会多多少少遇到它们的致命缺陷：

1. Docker资源感知问题：2019年1月，我们发现在阿里云上搭建的容器集群上，各种Java应用的Docker容器实例会间歇性地被 SIGKILL（signal=9）。原因是Docker容器利用CGroup对进程使用的资源进行限制，而在容器中的JVM依然会利用宿主机环境的内存大小和CPU核数进行缺省设置，这导致了JVM Heap的错误计算。我们做了两个措施来规避Docker OOM Killer：1）开启CGroup资源感知，目的是将heap堆内存和容器限制的内存设置成相同大小，2）将容器内存限制由2.5G调整为3G（注：2G（heap空间）+1G（额外） =3G），同时建议使用SpringBoot，它比较轻量，占用资源比较少，目前我司部分工程使用SpringCloud 设置为1G（heap空间）+1G（额外）=2G。

2. 阿里云镜像问题：2019年4月15日以及25日，我司在阿里云华北和华东机房的几台宿主机都曾突然出现IP地址缺失，导致上面跑的服务全部失联。此乃阿里云镜像的bug，对应于它的《KB:94181：检查与修复CentOS 7实例和Windows实例IP地址缺失问题》。我司随后检查所有机房并都通过脚本修复了。

3. Consul缺陷：2019年6月18日，有关键业务突然告警说它在nginx的注册地址1.1.1.1注册失败。原因是在内部容器注册的流程中，consul-template程序将consul中的数据读取出来，再写入nginx的upstream模块的配置中，但如果consul-template读取不到数据，则它会将默认地址1.1.1.1写入到upstream模块的配置中，从而为事故埋下了隐患。Consul官方已经在0.9.0以上新版本中修复此问题，我司随后逐一升级了所有机房的consul服务。

4. OKHTTP缺陷：2019年7月，据现场端反馈，即使在网络正常的情况下，也会有个别设备会在某个时段内出现支付缓慢，多笔交易连续失败的情况。原因是如果OKHTTP第一次出现SocketTimeoutException，后续即使网络已经恢复正常，请求也始终返回SocketTimeoutException，必须等到多活域名切换、重新连接WiFi，或重新启动应用程序才能恢复正常。此问题尤其是在4G网络下比较常见，官方未解决。我司只能在全局ResponseError监听器里，如果发现出现SocketTimeOut就清空连接池，并持续关注此issues修复状态，及时更新。

5. MySQL缺陷：2019年8月12日，数据中心的主从数据库宕机。原因是innodb做table truncate时候，要把属于这个table的表空间文件的所有的页刷盘并从buffer pool中去掉。代码中的判断应该存在问题，触发了实例crash。后续已将MySQL版本升级至较新版本5.7.27，同时将数据中心的数据库报表库和其他关键业务库拆分到不同实例，减小影响面。

 

-END-

感谢阅读老兵笔记，祝百病不侵鼠你健康！