这个Slack中断了吗？ 它始于AWS网络错误

Protocol获悉，Slack客户从2021年开始的数小时停机是一系列最初由AWS的网络扩展问题引起的级联问题的结果。

根据Slack上周（PST上午6:00）分发给客户的根本原因分析，我们开始体验到由于云提供商的网络边界之间的路由问题而导致的服务器之间的数据包丢失。 ＃34;一位熟悉该问题的消息人士证实，AWS Transit Gateway的扩展速度不足以适应1月4日上午假期休息期间对Slack服务的需求激增。

Slack除了确认报告的真实性外，拒绝发表评论。 AWS拒绝置评。

在接下来的一个小时中，由网络问题引起的数据包丢失导致Slack的服务器报告了越来越多的错误。随着越来越多的服务器被标记为“不健康”，这迫使健康服务器处理越来越多的需求。由于网络问题，他们缺乏响应能力。直到太平洋标准时间早上6:45左右，松弛的工程师才意识到这些问题。

＆＃34;太平洋标准时间（PST）上午7:00时，后端服务器的数量不足以满足我们的容量需求，＆＃34;根据该报告，Slack在全球范围内遭受重创。

Slack已经准备好要备份的服务器备用资源，但是开始发现它用来启动和验证那些备份服务器的预配服务存在问题，而该服务并非旨在处理试图使Slack正常运行并在多个服务器上运行的任务。短时间内可容纳1,000台服务器。报告还说，它的可观察性服务也受到网络问题的影响，因此也无法正确调试问题。

Slack告诉客户，在太平洋标准时间上午7点至太平洋时间上午8:15之间，AWS增加了AWS Transit Gateway的容量，并将Slack从共享系统迁移到专用系统。解决了Slack的预配系统问题之后，新服务器发现它们具有稳定的网络连接，并且在接下来的一个小时内服务开始恢复正常。

Slack在其报告中向客户承诺，它将在未来几个月内改进其体系结构的几个方面，首先是针对丢包的更好的警报系统，以及其可观察性系统与供应服务之间的紧密联系。它还将重新设计服务器供应服务，以处理类似类型的事件，并围绕服务器如何根据需求自动扩展设置新的规则。

尚不清楚的一件事是，AWS的人员如何协调他们对停机的响应：毕竟，AWS实际上是Slack的客户，因为两家公司去年6月签署了一项全面的合作伙伴协议。就其本身而言，Slack在2018年与AWS签署了一项为期五年的协议，该协议似乎可以满足2023年前其大部分云计算需求。

过去，当不成比例的大量人试图一次全部登录其服务时，Slack就遇到了问题。类似的中断发生在2017年的万圣节，当时发生了编码错误，导致Slack用户脱机，每个人都尝试同时登录。 ＆＃34;类似于DDoSing自己，＆＃34; Slack前基础架构总监Julia Grace当时告诉我。