在最近的一篇文章中，我们讨论了如何为我们的网络增加弹性。互联网的优势在于它能够将各种网络互联起来——大数据中心、小型托管公司的电子商务网站、互联网服务提供商（ISP）和内容交付网络（CDN）——仅举几个例子。这些网络要么直接使用专用的物理光缆，通过一个称为因特网交换（IXP）的通用互连平台相互连接，要么它们甚至可以通过被称为传输提供商的中介在因特网上进行连接来相互通信。互联网就像一个国家的公路网，在公路上导航意味着回答诸如"我怎么从亚特兰大到博伊西？"这个问题的互联网等价物是问如何从一个网络到另一个网络。例如，当您在Cloudflare博客上阅读本文时，您的web浏览器已连接到ISP，来自您计算机的数据包通过Internet到达Cloudflare的博客服务器。找出网络之间的路由是通过一个25年前设计的协议（在两张餐巾纸上）完成的，称为BGP。BGP允许网络间的互连动态变化。它提供了一个管理协议来交换网络之间的路由，并允许在某个路径不再可行的情况下（当某些路由不再工作时）撤销路由。互联网已经变得如此复杂，一组纠结的光纤、相邻的路由器和数以百万计的服务器，你可以确定随时都有一台服务器发生故障或光纤损坏。无论是在数据中心，铁路旁边的沟渠，还是在海底。现实情况是，随着连接的中断和固定，互联网处于不断变化的状态；它令人难以置信的优势在于它在现实世界中不断变化。BGP不提供一般的路由机制，也不提供自动处理这些事件的服务。尽管BGP能够优雅地处理网络的来来往往，但它并不是为了应对互联网的缺电而设计的。一个常见的问题是连接进入一个状态，它没有失败，但也不能正常工作。这通常表现为数据包丢失：数据包进入一个连接，却从未到达目的地。解决这些缺电的唯一办法是积极、持续地监测互联网的健康状况。2.0图片由Steve Jurvetson提供同样，道路系统的隐喻是有用的。打印出来的地图可以告诉你从一个城市到另一个城市的路线，但它不能告诉你哪里有交通堵塞。然而，现代GPS应用程序如Waze可以告诉你哪些道路拥堵，哪些道路畅通。类似地，互联网监控可以显示互联网的哪些部分被阻止或丢失数据包，哪些部分工作正常。在Cloudflare，我们决定部署自己的机制，以应对导致这些断电的不可预测事件。虽然大多数事件不在我们的管辖范围内-它们是Cloudflare网络的"外部"事件，但我们必须通过最小化外部事件的影响来运行可靠的服务。这是一个持续改进的过程，可以分解为几个简单的部分：建立一个详尽和一致的互联网质量观在此视图之上构建检测和警报机制建立自动缓解机制，确保最佳反应时间监控互联网我们已经在全球100个地点部署了我们的网络，我们处于一个独特的位置，可以从不同的地点监控互联网的质量。为此，我们利用网络硬件的探测功能，并添加了一些我们已经构建的额外工具。通过从数千个自动部署的探测器收集数据，我们可以实时查看互联网的基础设施：传输提供商的任何主干网中的数据包丢失，互联网交换中的数据包丢失，或各大洲之间的数据包丢失。随着时间的推移，观察这一实时视图，了解互联网部分故障的频率以及整个网络的恢复能力是有益的。我们的监控数据实时存储在由开源软件ZeroMQ、Prometheus和OpenTSDB组成的度量管道中。然后，可以在一个仪表板上查询和筛选数据，以使我们清楚地了解特定的交通服务提供商或某个特定的PoP的状态。上面我们可以看到一个传输提供商有一些包丢失问题的时间推移。2016年10月28日，我们看到美国西海岸的一家运输供应商遇到了一些麻烦。建立检测机制我们不想停在这里。拥有一个互联网质量的实时地图使我们处于一个很好的位置来发现问题并在问题发生时发出警报。我们已经定义了一组触发器，这些触发器表示网络问题，这使我们能够快速分析和修复问题。例如，在正常的互联网条件下，预计从拉丁美洲到亚洲的数据包丢失率为3%，而不是触发警报的情况。然而，欧洲两个国家之间3%的数据包丢失通常意味着一个更大、更具潜在影响的问题，因此将立即触发警报，让我们的系统可靠性工程和网络工程团队调查该问题。位于眼球网络和内容网络之间，我们很容易将此数据包丢失与系统中的各种其他指标关联起来，例如连接到客户源服务器的困难（表现为Cloudflare错误522）或来自本地ISP的流量突然减少。自动缓解收到有价值和可操作的警报是很好的，但是我们仍然面临着难以压缩的时间来反应因素。谢天谢地，在我们的早期，我们从DDoS攻击中学到了很多。我们已经了解了如何使用我们高效的自动化DDoS缓解管道检测和自动抵御大多数攻击。因此，我们自然想知道，我们是否可以将从DDoS缓解中学到的知识应用到这些通用的互联网事件中？毕竟，它们确实表现出相同的特征：它们不可预测，不在我们的网络之外，而且会影响我们的服务。下一步是将这些警报与自动操作关联起来。这些行动应该反映出一个随叫随到的网络工程师在提供相同信息的情况下会做些什么。这包括运行一些重要的检查：数据包丢失真的是在我们的网络之外吗？数据包丢失是否与实际影响相关？我们目前是否有足够的容量来重新路由流量？当所有的恒星都对齐时，我们知道我们有一个案例需要采取行动。综上所述，网络设备上的自动化操作比人们想象的要复杂得多。由于我们是一个多供应商的网络，我们没有过多地讨论细节，所以我们很难找到一种与我们的设备进行对话的通用语言。我们决定为杰出的开源项目Napalm做出贡献，将其与自动化框架Salt相结合，并对其进行改进以提供我们所需的特性。我们希望能够执行诸如配置探测、检索探测数据和管理复杂的BGP邻居配置等操作，而不管给定的PoP使用的是什么网络设备。将所有这些功能组合到一个自动化系统中，我们可以看到它所采取的措施的影响：在这里，您可以看到我们的一个运输供应商在香港突然遇到了问题。我们的系统会自动检测到故障并采取必要的措施，即禁用此链路进行路由。我们的系统每天都在不断改进，但它已经在高速运行，并在我们的网络中立即进行调整，以优化每一天的性能。在这里，我们可以看到在我们的缓解机器人90天内采取的行动。这样做的影响是，我们设法使互联网为我们的客户提供了更好的性能，并减少了他们在不使用Cloudflare时可能看到的错误数量。衡量这一点的一种方法是我们经常无法到达客户的来源地。有时起源完全离线。然而，我们越来越处在一个点，如果一个原点是可到达的，我们将找到一条到达它的路径。您可以在下面的图表中看到我们过去一年改进的效果。未来虽然我们每天都在不断改进这条弹性管道，但我们期待着部署一些新技术来进一步简化它：遥测技术将允许我们通过从"拉"模型到"推"模型来更实时地收集数据，像OpenConfig这样的新的自动化语言将统一和简化我们与网络设备的通信。我们期待着在这些改进成熟到可以发布时尽快部署。在Cloudflare，我们的使命是帮助建立一个更好的互联网。然而，就其性质和规模而言，互联网正处于不断变化之中——几乎在任何给定的时刻都会发生故障、被添加和被修复——这意味着服务经常被中断，流量在毫无征兆的情况下减慢。通过增强这个复杂网络的可靠性和弹性，我们认为我们离完成我们的使命和建设一个更好的互联网又近了一步。