从 1 月 27 日 22:15 UTC 开始，埃及的互联网服务在大约 20 分钟的时间内被广泛中断： 埃及如何杀死互联网。服务在 2 月 2 日大约 9:30 UTC 5 1/2 天后基本恢复：埃及路由活动概述 - RIPE
正如在埃及人抗议中的地面上所描述的那样，它破坏的不仅仅是浏览和消息传递：
在开罗国际机场附近的喜来登酒店工作的少数服务员不得不从一个房间跑到另一个房间，用他们的万能钥匙帮助客人进入他们的房间，因为酒店的磁力钥匙系统无法正常工作——它依靠互联网来更新客人的信息'键。
关于 DoS 攻击的后果，这里还有哪些可能令人惊讶的教训？
提醒我们，测试 24x7 基础设施是一个非常困难的问题。
依赖互联网接入的门锁，依赖未知网络资源的大型企业产品。如果您不能禁用部分环境以查看还有什么问题，那么您真的不知道。
显然，门锁不应该依赖于互联网访问，如果你决定它们应该依赖于正常工作的 LAN，你最好确保它完全在你的控制之下。
我曾在 NetApp 系统和 DNS 系统相互依赖的环境中工作过，而这只是在断电后将整个数据中心重新联机时才发现的。
我曾在所谓的独立、长达一小时的编译过程依赖于网络资源的环境中工作。仅当网络在软件发布的关键时刻出现故障时才发现这一点。
其他工程学科（水、电力等）几个世纪以来一直存在这个问题。
至少在 IT 环境中，您可以选择在某个孤立的地方自动重新创建您的环境，并查看当您重新创建的测试设置的一部分失效时会发生什么。
这实际上是我对“云”最大的担忧。
一切都依赖于可靠的高速网络。我个人尝试解决必须依赖可靠网络的问题：我有一个静态网站，而不是需要网络访问才能就地编辑内容的基于 Web 的 CMS，我有一个静态网站，当我在快速网络上时我可以离线编辑和上传.
我将我的 IMAP 帐户同步到本地磁盘，因此我不必等待网络延迟或服务可用性。
这些天我的大部分工作都存储在 git 中，因此我可以完全脱机工作，同时可以在快速网络上轻松备份和共享我的工作。
谷歌阅读器从互联网上获取内容并存储我所有的提要，直到我的离线客户端连接到谷歌阅读器并下载完整副本。无论这些网站有多糟糕，我都可以访问我想要的内容，因为只有我的计算机和 Google 之间的路由需要正常工作。
我知道这些都是非常简单的例子（有些例子，比如谷歌阅读器，有隐私问题），但任何时候你都可以设计一个允许完全离线模式的系统，同时在网络可用时充分利用它，我认为这是一个黄金设计拍摄。
就像一个建议：也许门锁应该能够将某种凭据缓存 X 小时或几天，以防止网络问题导致整个酒店无法运行。
每一个意图都有意想不到的后果。
始终拥有备份选项，或者不要仅在可通过 DoS 攻击的环境中运行关键任务系统。
好问题。
面对 DoS 时，有动力的用户会找到一种绕过损害的方法：
DoS 的成本可能很高。