
又一场波及数十万人的电子邮件风暴(Email storm)意外发生,这次的地点是在 GitHub 平台,事件主角是一位仅 18 岁的来自印度的年轻开发者 Rohith Sreedharan,他近日不小心给 GitHub 上约 40 万名用户发送了电子邮件。
事件起因
6 月 3 日,Rohith Sreedharan 向游戏公司 Epic Games 的 GitHub 仓库提交了一个平平无奇的PR,主要涉及修改 README 文件中的几处表述性问题,以及调整 logo 尺寸事项。

比如把“can”改成“may able to”
然而,Rohith 也许是为了让自己提交的 PR 尽快被合并,就在评论中 @了几个账号,其中一个是“EpicGames/developers”。接下来让 Rohith 万万没想到的结果是,此番 @EpicGames/developers 的操作触发了“Reply All”(回复所有人)事件。于是,他提交的这个 PR,被以邮件的方式通知给了 Epic Games 组织里的近 40 万名成员。

Epic Games 使用 GitHub 发布游戏引擎 Unreal Engine(虚幻引擎)的源代码,但它是通过添加用户到 “EpicGames/developers ”组织的方式来授予用户对其项目的访问权限,因此与其他 GitHub 组织相比,Epic Games 成员的数量异常庞大。
更让人“绝望”的是,一些人还收到了额外的 150 封通知,因为只要有人在这个 PR 下留言评论,对这个 PR 做出回应,这个动态也会被以邮件的方式继续通知给 Epic Games 组织成员。目前,该 PR 下有 155 条评论,据统计,这种默认的“Reply All”机制导致大约有 6614 万封电子邮件被发送。

由于邮件数量太多,GitHub 邮件通知服务一度出现延迟。所以开发者们收到邮件的时间不一,即使开发者在获知此事后手动取消订阅 PR,也还是会收到在此之前积压的未发出的邮件。
Rohith 本人对此事感到十分愧疚,并在推特上道歉称自己并不知道会因此发送邮件给 40 万个成员。

有不少网友认为这次责任不在于 Rohith,Rohith 不应该拥有执行此类操作的权限,GitHub 才应该为此负责,这件事反而是一次“漏洞”的警示。
“如果不是你,其他人可能也会触发相同的通知,这也可能会产生其他副作用。你在下一次事故发生之前就指出了它,从而挽救了下一次事故,没有什么好过度担心的。”
来自 GitHub 的高级工程师 Shay Frendt 也安慰 Rohith 道:“很抱歉,我们当前的系统设计导致你陷入这种情况。我们正在努力发布补丁,以尝试中断大家陷入的反馈循环。”
目前,Rohith 提交的 PR 已被关闭,Epic Games 将组重命名为“@EpicGames/terms-of-service-signatories”,并将“@EpicGames/developers”限制成请求访问以打开 PR 的人。
微软也中招过
让 Rohith Sreedharan 更惊讶的是,这次意外被“载入史册”,作为现实案例收录进了维基百科的Email storm(电子邮件风暴)词条中。

由“Reply All”引发的大规模电子邮件风暴在历史上偶有发生。2019 年 1 月 24 日,GitHub 也曾因 @Microsoft/everyone 的通知发生过类似事情,涉及过万名微软员工。
当时这事让不少人联想到 1997 年的传奇性的“Bedlam DL3”事件,在那次事件中,“Reply All”使微软的内部电子邮件服务器瘫痪了好几天。
1997 年那会,微软仍在解决 Exchange 的问题,这是家喻户晓的企业电子邮件服务器。为了进行测试,微软创建了一个邮件列表,上面有大约 25000 名员工,名为 Bedlam DL3。
一名微软员工注意到他们在“未知”的电子邮件分发群组“Bedlam DL3”上,于是通过电子邮件向该群组发送请求删除。这条信息发给了邮件组中的所有 25000 人。它引发了大量的回应--同样,一些人试图提供帮助,而其他人则开起了玩笑。但最常见的回复是一个简单的“我也是!”,这些人希望从 Bedlam DL3 列表和线程中退出。
考虑到所有这些信息,更不用说许多员工启用的阅读回执,这使得微软的电子邮件服务器几度停滞,而 IT 部门就不断想办法解决问题。
时至今日,Bedlam DL3 仍然是微软员工之间的一个笑话。让人啼笑皆非的是,2019 年这次风暴过去后,在 2020 年 3 月数千名微软员工又被卷入了一个“Reply All”电子邮件的线程。
在相继经历 2019/2020 年的这两次内部事件之后,微软在 2020 年 5 月终于推出一项新功能,用来防范 Office 365 Exchange 邮件服务器上的“Reply All”邮件风暴。这项防护功能可阻止所有包含 5000+ 收件人的电子邮件线程。触发功能后,Exchange Online 将在接下来的四个小时内阻止线程中的所有答复,以帮助服务器确定邮件的实际优先级,进而扑灭潜在的电子邮件风暴。
写在最后
“一封邮件掰倒整个系统”的囧事时有发生。毕竟总会有人不小心向一个涵盖 N 多人的邮件列表发送邮件,而一旦有人顺手“Reply All”,更别提有人设置了自动回复或已读回执的情况,这些迅速增长的邮件数量很容易导致电子邮件系统超载,使得运行速度大幅放缓。
那么,一个确保类似的情况不会发生在自己身上的建议是:当你被抄送到电子邮件或其他类型的信息时,不要“回复所有人”。
参考链接:
https://en.m.wikipedia.org/wiki/Email_storm
https://www.businessinsider.co.za/microsoft-employee-github-reply-all-email-storm-2019-1
评论 2 条评论