Facebook及其系列应用程序于 10 月 4 日消失超过5 小时，影响了全球超过 35 亿人并扰乱了已成为世界主要通信和商业平台之一的技术，这是多年来的技术中断。
然后，在上周五下午，Facebook 再次承认一些用户无法访问其平台。
这些由一系列人为和技术失误引发的背靠背事件不仅提醒我们对 Facebook、Instagram、Messenger 和 WhatsApp 的依赖程度，而且还提出了一个问题：如果这样不幸可能降临在使用最广泛的社交媒体平台上，任何网站或应用程序安全吗?
令人不快的答案是否定的。不同范围和持续时间的停电是上周之前的生活事实，之后也会发生。技术崩溃，人们犯错，事情发生了。
对于每家公司来说，正确的问题一直是，而且仍然不是是否会发生中断——当然可能——而是可以做些什么来降低风险、持续时间和影响。
我们观看了这些剧集——根据各种估计，Facebook 在 10 月 4 日花费了 60 到 1 亿美元的广告费用——从业内人士在管理中断方面的独特视角展开。
我们中的一个人 (Anurag) 曾在 Amazon Web Services 担任副总裁七年多，目前是一家专门研究网站和应用程序性能的公司的创始人兼首席执行官。另一个 (Niall) 在 Microsoft Azure 担任站点可靠性工程 (SRE) 全球负责人 3 年，在此之前 11 年在 Google 担任同一专业。我们一起经历了无数科技巨头的停电。
以各种方式，这些中断应该成为组织审视内部的警钟，并确保他们创造了正确的技术和文化氛围，以防止或减轻类似 Facebook 的灾难。他们应该采取四个关键步骤：
1. 承认人为错误是既定的，并致力于弥补它
值得注意的是，IT 崩溃经常以打字错误开始。
根据Facebook 基础设施副总裁 Santosh Janardha的解释，工程师们正在执行日常网络维护时，“发出命令旨在评估全球骨干网容量的可用性，这无意中切断了我们骨干网中的所有连接，有效地断开了连接。 Facebook 全球数据中心。”
这让人想起2017 年 2 月亚马逊网络服务 (AWS)中断，导致大量网站无法运行数小时。该公司表示，其一名员工正在调试计费系统的一个问题，意外使更多的服务器脱机，导致更多系统出现级联故障。人为错误导致了2011 年 4 月之前的一次大规模 AWS中断。
公司不能假装只要更加努力，就可以阻止人类犯错。现实情况是，如果每天有数百人手动键入数千个命令，那么有人犯下灾难性的失误只是时间问题。相反，公司需要调查为什么命令行中看似很小的失误会造成如此广泛的损害。
底层软件应该能够自然地限制任何单个命令的爆炸半径——实际上，限制受单个命令影响的元素数量的断路器。根据 Janardha 的说法，Facebook 拥有这样的控制权，“但该审计工具中的一个错误使其无法正确停止该命令。”教训：公司需要努力检查这些功能是否按预期工作。
此外，组织应该寻求自动化技术来减少重复的、通常是乏味的手动流程的数量，这些流程会发生如此多的失误。自动化还需要断路器，以避免维修失控并导致更多问题。Slack在 2021 年 1 月的中断表明自动化也可能导致级联故障。
2. 进行无可指责的事后分析
Facebook 的马克扎克伯格在 10 月 5 日写道，“过去 24 小时我们一直在汇报如何加强我们的系统以应对这种故障。”这很重要，但它也提出了一个关键点：遭受停电的公司永远不应该指责个人，而应该考虑哪些系统和流程可能会阻碍它的大局。
正如杰夫贝索斯曾经说过的，“好意是行不通的。机制可以。”他的意思是，尝试或努力工作并不能解决问题，您需要修复底层系统。这里也是一样。没有人早上起床打算犯错，他们只是发生了。因此，企业应着眼于减少错误的技术和组织手段。对话应该是这样的：“我们已经为这次停电付出了代价。我们可以从这笔支出中得到什么好处?”
3.避免“致命拥抱”
致命拥抱描述了当网络中有太多系统相互依赖时发生的死锁——换句话说，当一个系统崩溃时，另一个系统也失败了。
这是 Facebook 宕机的一个主要因素。这个单一的错误命令引发了多米诺骨牌效应，关闭了连接 Facebook 全球所有数据中心的主干。
此外，Facebook 的 DNS 服务器的问题——DNS，域名系统的缩写，将人类可读的主机名转换为数字 IP 地址——“破坏了我们通常用来调查和解决此类中断的许多内部工具，”Janardha 写道。 .
这里有一个很好的教训：保持对网络中的依赖关系的深刻理解，这样如果出现问题，你就不会措手不及。并有冗余和回退，以便解决中断的工作可以快速进行。这种想法应该类似于，如果自然灾害使急救人员的现代通信系统瘫痪，他们仍然可以转向诸如业余无线电频道之类的旧技术来完成他们的工作。
4. 支持去中心化 IT 架构
许多科技行业内部人士可能会惊讶地发现 Facebook 在其 IT 方法中是多么的单一。无论出于何种原因，该公司都希望以高度集中的方式管理其网络。但这种策略使停电情况比应有的情况更糟。
例如，他们将自己的 DNS 服务器完全置于自己的网络中，而不是通过外部 DNS 提供商部署在云中的一些服务器，当内部无法访问时，这些服务器可以访问，这对他们来说可能是一个错误。
另一个问题是 Facebook 使用“全球控制平面”——即公司全球所有资源的单一管理点。有了更加分散的区域控制平面，应用程序可能会在世界的某个地方下线，比如美国，但继续在欧洲和亚洲工作。相比之下，AWS 和 Microsoft Azure 使用这种设计，而 Google 已经朝着它迈进了一些。
Facebook 可能遭受了所有停电之母——并且背靠背——但这两集都为其他公司提供了宝贵的经验教训，以避免同样的命运。这四个步骤是一个很好的开始。
