关于FB outage的一些分析

根据鄙人自学system design的经验，系统可靠性的提高靠冗余，Facebook不会没给自家的DNS服务器设计冗余吧？

hesd10 发表于 2021-10-5 09:47
根据鄙人自学system design的经验，系统可靠性的提高靠冗余，Facebook不会没给自家的DNS服务器设计冗余吧？

应该不是FB自己家的DNS服务器引起内部炸掉，再连带外部一起炸的，可能是别的原因，造成全球用户ping个不停，接着公域几个根节点host里的那些服务器 overloaded，阻塞了。

hesd10 发表于 2021-10-04 18:47:36
根据鄙人自学system design的经验，系统可靠性的提高靠冗余，Facebook不会没给自家的DNS服务器设计冗余吧？

这种量级的冲击，可能secondary跟着阵亡了。所以我们得来一套10个才行。。。

NQYY 发表于 2021-10-04 17:00:32
好问题 需要对network infrastructure有很深的理解

那是，能面进fb的都是大佬。理解那是相当深刻

系统设计的rate limit，不是防止这种情况发生的吗?

有很多人问关于retry的问题

其实这个retry来自于多方面 可以来自DNS resolver自己，也可以来自浏览器，也可以来自用户手动刷新，又或者是运营商中间的哪个layer。

举个简单的栗子：每一次facebook.com的request，DNS resolver自己retry3次，你用的chrome浏览器retry3次，加载不出来你非常着急自己再点浏览器refresh三次 这乘在一起就是3*3*3=27次。这还不考虑中间某些其他layer。

这仅仅是一次对facebook的request被放大了几十倍。这对于很多dns resolver简直是噩梦。于是纷纷承受不了就炸了。于是别网站的request也变慢，大家刷新的更多了，恶性循环。

有时候很多小东西经过乘积或指数放大有比预想要大得多且可怕的多的影响。

yiliaobailiao 发表于 2021-10-4 22:59
系统设计的rate limit，不是防止这种情况发生的吗?

一般rate limit都是per IP的而且这个值会设置的比较大 全球的人都在用facebook就没办法

哎……运维人员难啊，不出事没人注意到你的贡献。出事了就down这么长时间，能力水平有问题。感觉绝大部分工资都非常重视核心部门，运维老被忽视。

BGP配置没有roll back plan？非死不可这个真是很严重的事故。

补充内容 (2021-10-06 01:20 +8:00):
绝大部分公司……

重读FB在今年NSDI上的论文

We demonstrate how this design provides us with flexible control over routing and keeps the network reliable. We also describe our in-house BGP software implementation, and its testing and deployment pipelines. These allow us to treat BGP like any other software component, enabling fast incremental updates.

---- "Running BGP in Data Centers at Scale"

剑随风飘 发表于 2021-10-4 16:28
System design: design a configuration to blow up the whole internet

看来FB招聘需要改进啊，系统设计