Slack

Slack 2021 年 1 月 4 日的中断始于一个过载的托管云传输枢纽，但并未止步于此。AWS Transit Gateway 上的数据包丢失与 Slack 自身的监控布局、健康检查、自动扩展信号、配置限制和恢复控制相互作用。结果是，在许多人依赖 Slack 进行远程工作和学校的第一工作日发生了广泛中断。因此，该事件作为一次问责案例比作为一个简单的云服务失败故事更有用。事实记录支持一个共享控制的解释。Slack 表示 AWS 控制了 Transit Gateway 的扩展，并在 AWS 监控发现问题后手动增加了容量。Slack 控制了围绕该网关的架构：VPC 关系、监控路径、网络层、配置服务、自动化规则、配额和资源上限，这些共同决定了数据包丢失如何演变为一次长时间的服务故障。企业客户无法控制两家公司的基础设施，但他们控制着自己对协作平台的依赖程度以及当平台失效时有哪些替代方案可用。这种分配并不确立法律责任、过失或服务水平协议违约。它基于谁能够观察、改变、测试或验证每个控制面进行的运营分析。这种区分很重要。将事件称为“AWS 中断”会隐藏 Slack 的故障放大条件。

Slack's January 4, 2021 outage began with an overloaded managed cloud transit hub, but it did not end there. Packet loss across an AWS Transit Gateway interacted with Slack's own monitoring placement, health checks, autoscaling signals, provisioning limits and recovery controls. The result was a broad disruption on the first working day of the year for many people who had come to depend on Slack for remote work and school. The incident is therefore more useful as an accountability case than as a simple story about one cloud service failing. The factual record supports a shared-control explanation. Slack said AWS controlled the Transit Gateway's scaling and manually increased its capacity aft