Facebook宕机背后,我们该如何及时发现DNS问题

简介: 国庆期间,Facebook 及其旗下 Instagram 和 WhatsApp 等应用全网宕机,停机时间将近 7 小时 5 分钟,Facebook 市值损失 643 亿美元。针对Facebook的宕机问题,我们该如何未雨绸缪,看看云拨测如何帮助客户避免该类问题。

在我们享受国庆假期的时候,大洋对岸的互联网世界却出了一件重大“事故”:Facebook 及其旗下 Instagram 和 WhatsApp 等应用全网宕机,停机时间将近 7 小时 5 分钟,浏览器在尝试打开时显示 DNS 错误。这对于旗下应用群月活和日活高达 35.1 亿和 27.6 亿的 Facebook 而言,可谓损失惨重。据投资机构估计,7 小时宕机导致超过 9.68 亿美元影响成本。并直接让 Facebook 市值损失 643 亿美元,其创始人马克·扎克伯格净资产蒸发 70 亿美元。


1.png


Facebook 表示,故障根本原因是例行维护工作出了问题,协调数据中心之间网络流量的骨干路由器配置变化,继而导致其 DNS 服务器发生问题并致使内部工具和系统被关闭,运维人员无法远程访问设备以便恢复网络。因此,运维人员不得不进入有着流程措施严格的数据中心进行人工重启。因此,MTTR 被严重拖长。


一句话总结,一条糟糕的命令、一款有缺陷的审核工具、一套阻碍成功恢复网络的 DNS 系统以及繁琐的数据中心流程,共同导致了 Facebook 长达 7 个小时的重大故障。


具体而言,运维人员对骨干网络的一部分进行断网维护。例行维护的一部分就是评估全球骨干网容量的可用性,但无意间中断开了骨干网络所有连接,也断开了 Facebook 全球数据中心的连接。与此同时, 由于 Facebook 的架构设计是根据服务器可用性来扩展或缩减 DNS 服务。当服务器可用性因网络故障而降至零时,就会停用所有 DNS 服务器。自动响应骨干网崩溃似乎成为导致 DNS 瘫痪的原因。这种停用通过 Facebook 的 DNS 名称服务器向互联网边界网关协议(BGP) 路由器发送消息来完成的,这些路由器存储用来抵达特定 IP 地址的路由方面的信息。这些路由通常被公告给路由器,让路由器了解如何适当地引导流量。


Facebook 的 DNS 服务器发送的 BGP 消息禁用了公告给路由,因此无法将流量解析成 Facebook 骨干网络上的任何对应内容。最终结果就是,即使 DNS 服务器仍在运行,也访问不了,用户也会因试图访问的网络崩溃而丢失服务。更不幸的是,DNS 服务用于面向客户的网站,还将其用于自己的内部工具和系统。


看到这里我们会发现,DNS 在这其中扮演着重要的角色,那么 DNS 又是什么?DNS 即Domain Name System 的缩写,域名系统以分布式数据库的形式将域名和IP地址相互映射。简单的说,DNS 是用来解析域名的,在正常环境下,用户的每一个上网请求会通过 DNS 解析指向到与之相匹配的IP地址,从而完成一次上网行为。DNS 作为应用层协议,主要是为其他应用层协议工作的,包括不限于 HTTP 和 SMTP 以及 FTP,用于将用户提供的主机名解析为 IP 地址,具体过程如下:


(1)用户主机(PC 端或手机端)上运行着 DNS 的客户端;
(2)浏览器将接收到的 URL 中抽取出域名字段,就是访问的主机名,比如http://www.aliyun.com/ , 并将这个主机名传送给 DNS 应用的客户端;
(3)DNS 客户机端向 DNS 服务器端发送一份查询报文,报文中包含着要访问的主机名字段(中间包括一些列缓存查询以及分布式 DNS 集群的工作);
(4)该 DNS 客户机最终会收到一份回答报文,其中包含有该主机名对应的IP地址;
(5)一旦该浏览器收到来自 DNS 的 IP 地址,就可以向该 IP 地址定位的 HTTP 服务器发起 TCP 连接。


Facebook 此次宕机持续近 7 小时影响了约 8500 万用户,是自 2008 年以来最严重的一次。作为旁观者回顾这次故障,我们会发现一个非常关键的问题点:但据了解,当日不断有用户反映,Facebook 旗下 Facebook、移动聊天服务 Messenger 和 WhatsApp、图片社交服务 Instagram 等四大社交平台网站和应用均发生响应服务器错误,导致无法刷新。Facebook 在欧洲、美洲、大洋洲几乎完全下线,在亚洲的日本、韩国、印度等国也无法访问,影响到全球数十个国家和地区用户。似乎 Facebook 似乎并没有在第一时间发现这些问题。只在全球多个国家和地区用户进行反馈后才发现了问题。


即使是庞大如 Facebook 这样的企业,也没有在第一时间发现 DNS 故障,并遭受严重的经济损失。设身处地的面对这样故障,我们该如何第一时间发现并监控产品以及 DNS 的运行状况?并且及时了解全球不同国家和地区的用户使用情况?


纵观各类 APM 产品,无侵入的云拨测成为最佳的解决方案。阿里云拨测通过遍布全球的 1000+ 监测点,包括真实用户监测,全天候 24 小时对目标域名发起网络请求,帮助用户监测 DNS 服务对可用性和解析性能,同时 DNS 拨测支持指定递归、迭代不同查询方式以及解析服务器,通过灵活的拨测参数配置尽可能模拟真实用户的访问。


2.png


经过定时的拨测任务,阿里云拨测可以生成不同地区的 DNS 解析用时的报表,同时针对每次拨测都清晰的列出 DNS 请求对详情,包括 A 地址、DNS 用时、DNS 解析过程等,能给帮助用户快速分析和定位 DNS 解析的问题。


另外通过配置 DNS 告警,针对于 DNS 的可用性问题和解析性能问题,也可以先于用户感知并问问题的修复争取时间,提高用户的满意度,降低经济损失。


3.png


想要避免类似的问题,那就开始使用云拨测吧

目前云拨测提供 15 天免费试用

新用户购买更有 9 折优惠!

点击下方链接,了解更多详情!

https://www.aliyun.com/activity/middleware/website/performance/test?spm=5176.20960838.0.0.6d33305emfVIyC


部分内容引用自
1.《欧界丨Facebook出现史上最严重宕机,7个小时烧掉60亿》

https://www.163.com/dy/article/GLI6PFA70552C1I4.html
2.《Facebook大故障原因》

https://baijiahao.baidu.com/s?id=1712926610001333324&wfr=spider&for=pc


相关文章
|
存储 运维 Prometheus
全面公测|Grafana服务:一张图表胜过千行指标&日志
Grafana 帮助运维人员轻松处理各类运维过程中遇到的各类数据可视化与分析难题。目前阿里云 Grafana 服务全面免费公测,帮助企业轻松构建运维数据可视化平台,轻松实现数据驱动运维!
2843 123
全面公测|Grafana服务:一张图表胜过千行指标&日志
|
存储 运维 搜索推荐
如何在千亿行规模的表中快速检索数据
小数据量的数据可以用 MySQL 存储和查询,但是数据量变多后,比如超过 2000万,甚至超过200亿后数据该选择哪个系统才能实现存储和查询两不误?这篇文章会介绍如何存储千亿行数据,以及如何在其实进行查询,而且这些都是在一个系统里面就能做到。
3883 118
如何在千亿行规模的表中快速检索数据
|
Arthas 运维 监控
线上故障突突突?如何紧急诊断、排查与恢复
稳定性大于一切,因此我们需要有更有效的方式避免线上故障。在发生故障不可避免的假设下,我们需要能够快速修复,减少线上影响。基于以上这些想法,我们提出了 1-5-10 的快恢目标,所谓 1-5-10 的目标就是是要我们对于线上问题能够做到 1 分钟发现,5 分钟定位,10 分钟修复。下面将会介绍一些阿里云上关于故障恢复、诊断的一些最佳实践。
线上故障突突突?如何紧急诊断、排查与恢复
|
缓存 运维 监控
面对DNS劫持,只能坐以待毙吗?
借助 ARMS-云拨测,我们可实时对网站进行监控,实现分钟级别的监控,及时发现 DNS 劫持以及页面篡改。
面对DNS劫持,只能坐以待毙吗?
|
消息中间件 存储 Cloud Native
阿里云 EventBridge 事件驱动架构实践
我们认为 EventBridge 是云原生时代新的计算驱动力,这些数据可以驱动云的计算能力,创造更多业务价值。
阿里云 EventBridge 事件驱动架构实践
|
存储 运维 监控
【CDS技术揭秘系列 总篇】阿里云的云定义存储来了
全新发布的云定义存储 CDS 和传统的存储阵列、分布式存储、软件定义存储的区别在哪里?阿里云存储团队如何看待将来存储的发展趋势?本文邀请了 CDS 研发团队的核心技术负责人为大家揭开围绕着阿里云 CDS 的种种谜团。
5370 0
|
敏捷开发 消息中间件 运维
浩鲸科技基于ChaosBlade的混沌工程实践
浩鲸科技在海量互联网服务以及当前爆炸式增长的流量场景实践过程中,沉淀出了包括,链路压测,流控管理,动态扩缩容,故障演练等高可用核心技术,并通过云上服务化、平台化和工具化的形式,帮助内部产品研发部门以及客户,提高开发效率,提升业务稳定性。 为了打通故障发现,故障管理,故障演练,应急响应等多方高可用措施,形成稳定性建设的完整链路。浩鲸科技组建 IT 蓝军,实施演练突袭,质量控制,联合作训。自2019年开始建设 IT 蓝军队伍,重点围绕生产环境,开展混沌工程实践,以推动代码、基础设施、流程、人员、监控上的提升。自今年起,深化演练力度,演练常态化、周期化,不断提高 SRE 单兵作战能力。
浩鲸科技基于ChaosBlade的混沌工程实践
|
存储 SQL NoSQL
如何破解HBase+Elasticsearch组合使用遇到的难题
面对海量数据的低成本存储+高效检索需求,业界通常使用HBase+ElasticSearch的组合方案,本文将介绍该方案的常见实现架构及其痛点,并提出一种更好的解决方法Lindorm Searchindex
4579 1
如何破解HBase+Elasticsearch组合使用遇到的难题
|
Cloud Native 安全 Devops
EMAS 移动 DevOps 解决方案 —— Mobile DevOps
DevOps这一优秀的软件交付理念在服务端已经有很多相关的实践,那么是否也可以应用到移动端进行交付呢?基于移动端和服务端场景的差异,移动DevOps跟服务端DevOps又有哪些不同和挑战?本文分享阿里云云原生应用研发平台EMAS在建设云原生Mobile DevOps过程中的思考、遇到的挑战以及解法,解密其设计架构和技术细节。
9390 2
EMAS 移动 DevOps 解决方案 —— Mobile DevOps
|
存储 数据采集 搜索推荐
基于Lindorm的大数据用户画像解决方案
本文从用户画像的业务特征出发,全方位、多角度分析了Lindorm作为面向大数据的存储为什么是用户画像业务合适的存储选择。旨在帮助读者遇到类似需求时可以少走弯路,一步到位作出合适的存储选型。
10528 1
基于Lindorm的大数据用户画像解决方案