Simone
看了facebook此次的事故，是有个多个因素一起促成的一个大事故。而其中的任何单一事故，都不算特别严重，在各个互联网公司里也时常发生。但就是这些小事故集合在一起时，才完成了这个震惊业界的大炮仗。
先回溯一下问题过程。运维工程师对WAN配置做变更，一处配置错误导致了一个网段在互联网上消失了。单这一步，就足以影响facebook的多种服务了，但不是全部服务。但facebook的全部4个DNS服务器IP也在这个网段里。导致了facebook旗下所有服务的域名解析失败。后续就是运维层面的内部困难了，比如机房门禁系统也需要依赖域名访问内部服务做认证。
产生如此事故最初的原因是运维工程师的WAN配置失误。现实的WAN配置是很复杂的，对大型互联网公司来说，几乎无法依靠人工来完成设置。WAN配置是对互联网上的路由器进行规则配置。当数据包到达时，根据规则判定要将其转发到其他路由器。对计算机网络来说，根据目标地址设置转发目的地需要个映射，几种典型的映射：
而在互联网这个级别，各个路由器之间就是通过BGP协议实现的。其通过广播的方式，向相邻的其他路由器声称自己可以负责转发某些子网的数据包。其他路由器收到该信息后，就会自动记录下来，并在之后自动将对应子网的数据包转发到这台路由器。BGP设计的较早，早期设计缺乏安全性考虑，也导致过一些事故。比如2008年巴基斯坦就通过BGP劫持了全世界的Youtube流量，导致Youtube下线两小时。
由此可见，BGP是负责各个路由器之间声明子网映射的协议。其他路由器都是默认信任其广播信息的。此次facebook事故也是源于错误的BGP配置，将自己持有的子网AS32943声明丢失了。于是所有需要发送到该子网的数据包就全部没了目的地，在网络中消失了。这其中就包含很多对facebook旗下各种服务的DNS查询请求。
路由器配置对运维工程师来说是很有挑战的。一条路由器规则由3个部分组成：入口条件，路由选择，出口条件。路由表的配置由很多条这样的规则组成，互相之间还有顺序依赖，比如入口条件为子集的放在后面就不会命中，而是在前面就转发走了。同时各种路由器制造商，在规则语句的执行上也有少许区别，导致相同的配置在不同厂商，不同型号的路由器上可能得到完全不同的结果。甚至在多个路由器的环境里，配置到达路由器的先后顺序也可能导致事故。这些问题使得配置大型互联网公司的路由表变得难上加难。
正是因为手工配置路由器困难重重，于是也有一些开源软件来辅助，用来自动检查路由器配置，以及生成的网络拓扑图。比如batfish就是其中较为著名的一个。但batfish功能较少，比如没有区分路由器制造商的检查功能，以及路由失败时错误配置的显示。但在搜索中，发现了阿里巴巴的运维部为了解决互联网路由器配置，开发了一套更加强大的工具，HOYAN。通过HOYAN，可以通过读取路由器配置，自动检查是否有哪些规则被屏蔽，分析网络的拓扑结构，寻找网络不可达的情况，以及失败配置时的拓扑。使得路由器配置编写好以后，实际生效之前能够得到完善的检查，避免facebook这样的运维事故。
论文的标题和摘要如下：
论文全文下载：
路由配置的检查面临诸多困难。为此HOYAN对阿里巴巴所使用的路由器进行了路由器行为建模，以确保路由配置可以针对不同品牌型号路由器产生针对性的仿真结果，并生成网络拓扑。进而在基于网络拓扑来分析各个子网之间的连通性。尤其是针对大型网络，连通性靠人来分析已经非常不显示了。而依靠对网络拓扑图的有向图遍历，则可以分析出来网络不可达的情况。即此次facebook错误配置中的问题。
中国的互联网企业在发展过程中，往往面临着巨大的流量压力，和复杂很多的网络状况。比如阿里巴巴在全世界有数十个数据中心，比Google和facebook的数据中心更多，进而导致了网络配置的复杂性更高。这也督促着运维工程师更早的引入自动化工具来辅助工作流程，比如此次完全有机会预先发现路由配置错误的HOYAN系统。通过这些自动化系统，不仅使得工作的可靠性提高，也使得很多工作基于规则自动完成，而避免依靠人在紧急状况下的判断，避免了事故隐患。
facebook此次事故的教训，依旧是老生常谈的那几点，注重上线前检查，建立规范而带有审计的上线流程等等。但HOYAN系统的例子，也使得我们更应该注意整个信息基础架构中的自动化系统，毕竟这玩意真的可以避免事故，保住自己的年终奖。
