事实证明，2019年夏季的第一个月末和第二个月初是困难的，世界IT服务出现了几次大幅下降。 其中值得注意的是：CloudFlare基础架构中发生了两次严重事件（第一起事件-来自美国的某些ISP弯曲双手，对BGP粗心大意；第二起事件-CF本身的部署不正确，影响了所有使用CF的人，并且这些都是许多值得注意的服务）； Facebook CDN基础结构的不稳定运行（影响了所有FB产品，包括Instagram和WhatsApp）。 尽管在全球背景下我们的停运情况要少得多，但我们也必须接受分配。 有人已经开始拖入黑色直升机和“主权”阴谋，因此，我们将对此事件进行公开验尸。
07/03/2019，16:05我们开始修复资源问题，类似于违反内部网络连接的问题。 由于没有完全检查所有内容，他们开始在数据线方向上破坏外部通道的可操作性，因为很明显内部网络访问Internet（NAT）存在问题，直到他们将BGP会话置于DataLine方向为止。
07/03/2019，16:35很明显，执行网络地址转换以及从站点的局域网访问Internet（NAT）的设备失败了。 尝试重新启动设备并没有带来任何结果，因此在获得技术支持的响应之前就开始寻求用于组织连接性的替代选项的搜索，因为从经验上来看这可能无济于事。
由于该设备还终止了客户端VPN员工的传入连接，因此使远程恢复工作变得更加困难，这一事实使问题变得更加严重。
07/03/2019，16:40我们试图重新激活以前曾努力工作的NAT后备方案。 但是很明显，由于网络的大量重新装备，使该方案几乎完全无法使用，因为在最佳情况下恢复该方案可能无法正常工作，而在最坏的情况下，它会破坏已经正常运行的方案。
他们开始提出一些想法，以将流量转移到为骨干网服务的新路由器中，但是由于核心网络中路由分配的特殊性，它们似乎无法工作。
07/03/2019，17:05同时，在名称服务器上解析名称的机制中发现了一个问题，这导致解析应用程序中的端点时出错；它们开始用关键服务的记录快速填充主机文件。
07/03/2019，17:27恢复了Habr有限的功能。
07/03/2019，17:43但是最后，找到了一种相对安全的解决方案，用于组织通过边界路由器之一的流量，该边界路由器很快被连根拔起。 互联网连接已恢复。
在接下来的几分钟内，监视系统收到了许多有关恢复监视代理程序工作能力的通知，但是由于中断了名称服务器（dns）上的名称解析机制，某些服务却无法正常工作。
07/03/2019，17:52NS重新启动，缓存被重置。 解决后恢复。
07/03/2019，17:55获得了除MK，Freelansim和Toaster之外的所有服务。
07/03/2019，18:02获得MK和Freelansim。
07/03/2019，18:07恢复了与DataLine的纯真的BGP会话。
07/03/2019，18:25他们开始固定资源的法兰，这与NAT池的外部地址的更改相关联，并且在许多服务中均不存在该地址，因此很快进行了纠正。 立即获得和烤面包机。
07/03/2019，20:30我们注意到与Telegram机器人相关的错误。 原来，他们忘记了在一对acl（代理服务器）中注册外部地址，因此他们迅速对其进行了更正。
结论
- 设备故障，甚至在此之前就对其适用性产生了怀疑。 有计划将其排除在外，因为它会干扰网络的发展并存在兼容性问题，但同时它也起着至关重要的作用，这就是为什么在技术上不中断服务就不容易进行替换的原因。 现在您可以继续。
- 可以通过将DNS移到NAT网络之外的新主干网，并同时与灰色网络完全连接而不进行转换来避免DNS问题（这是在事发前计划的）。
- 组装RDBMS群集时不要使用域名，因为透明更改IP地址的便利性并不是特别必要，因为所有这些操作都需要群集重组。 该决定是由历史原因决定的，首先是由RDBMS配置中按名称显示的端点的明显性决定的。 一般来说，是一个经典的陷阱。
- 原则上，已经进行了与“鲁内特主权化”相当的练习，从加强自主生存的可能性的角度出发，需要考虑一些事情。