2019 年夏季第一个月末和第二个月开始的日子很艰难，全球 IT 服务出现了几次大幅下降。 其中值得注意的是：CloudFlare 基础设施中发生的两起严重事件（第一起 - 来自美国的一些 ISP 的不法行为和对 BGP 的疏忽态度；第二起 - CF 本身的不正当部署，影响了每个使用 CF 的人，以及许多值得注意的服务）以及 Facebook CDN 基础设施运行不稳定（影响了所有 FB 产品，包括 Instagram 和 WhatsApp）。 我们还必须陷入分发的困境，尽管我们的中断在全球背景下不太明显。 有人已经开始拖入黑色直升机和“主权”阴谋，因此我们将发布事件的公开事后分析。
03.07.2019，16：05
资源问题开始被记录，类似于内部网络连接故障。 在没有完全检查所有内容后，他们开始对通往 DataLine 的外部通道的性能提出错误，因为很明显问题出在内部网络对 Internet (NAT) 的访问上，以至于将 BGP 会话置于 DataLine 上。
03.07.2019，16：35
很明显，提供网络地址转换和从站点本地网络访问互联网 (NAT) 的设备发生了故障。 尝试重新启动设备并没有导致任何结果，在收到技术支持的响应之前就开始寻找组织连接的替代选项，因为根据经验，这很可能没有帮助。
该设备还终止了客户端 VPN 员工的传入连接，这在一定程度上加剧了问题，并且远程恢复工作变得更加难以执行。
03.07.2019，16：40
我们试图恢复以前运行良好的现有备份 NAT 方案。 但很明显，多次网络整修使该计划几乎完全失效，因为它的修复充其量可能不起作用，或者在最坏的情况下，会破坏已经起作用的东西。
我们开始研究一些想法，将流量传输到一组为骨干网服务的新路由器，但由于核心网络中路由分布的特殊性，这些想法似乎行不通。
03.07.2019，17：05
与此同时，在名称服务器上的名称解析机制中发现了一个问题，这导致应用程序中解析端点时出现错误，并且他们开始用关键服务的记录快速填充主机文件。
03.07.2019，17：27
哈布尔的有限功能已恢复。
03.07.2019，17：43
但最终，找到了一种相对安全的解决方案，通过其中一个边界路由器来组织流量，并很快安装了该解决方案。 互联网连接已恢复。
在接下来的几分钟里，监控系统发出了大量关于监控代理功能恢复的通知，但由于名称服务器（dns）上的名称解析机制被破坏，一些服务无法运行。
03.07.2019，17：52
NS 重新启动并清除缓存。 解析已恢复。
03.07.2019，17：55
除 MK、Freelansim 和 Toaster 外，所有服务均开始工作。
03.07.2019，18：02
MK 和 Freelansim 开始工作。
03.07.2019，18：07
使用 DataLine 恢复无辜的 BGP 会话。
03.07.2019，18：25
他们开始记录资源问题，这是由于NAT池的外部地址发生变化，以及一些服务的acl中缺少该问题造成的，很快就得到了纠正。 烤面包机立即开始工作。
03.07.2019，20：30
我们注意到与 Telegram 机器人相关的错误。 事实证明，他们忘记在几个 acl（代理服务器）中注册外部地址，这一问题很快就得到了纠正。
发现
- 该设备此前曾引发对其适用性的质疑，但最终失败了。 有计划将其从工作中消除，因为它干扰了网络的发展并存在兼容性问题，但同时它执行了关键功能，这就是为什么在不中断服务的情况下进行任何替换在技术上都很困难。 现在你可以继续前进了。
- 通过将它们移近 NAT 网络之外的新骨干网络，并且仍然与灰色网络保持完全连接而无需转换（这是事件发生之前的计划），可以避免 DNS 问题。
- 在组装 RDBMS 集群时不应该使用域名，因为透明地更改 IP 地址的便利性并不是特别必要，因为此类操作仍然需要重建集群。 这一决定是由历史原因决定的，首先是 RDBMS 配置中端点名称的明显性。 总的来说，是一个经典的陷阱。
- 原则上已经进行了类似“符文主权化”的演习；在加强自主生存能力方面有一些值得思考的地方。
来源： habr.com