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-

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

 

posted @ 2020-02-11 18:45  旁观者  阅读(1592)  评论(1编辑  收藏  举报