印度萌新令人绝望的操作:提交 PR“轰炸”近 40 万开发者,GitHub 负责?

简介: 又一场波及数十万人的电子邮件风暴(Email storm)意外发生,这次的地点是在 GitHub 平台,事件主角是一位仅 18 岁的来自印度的年轻开发者 Rohith Sreedharan,他近日不小心给 GitHub 上约 40 万名用户发送了电子邮件。

又一场波及数十万人的电子邮件风暴(Email storm)意外发生,这次的地点是在 GitHub 平台,事件主角是一位仅 18 岁的来自印度的年轻开发者 Rohith Sreedharan,他近日不小心给 GitHub 上约 40 万名用户发送了电子邮件。

事件起因

6 月 3 日,Rohith Sreedharan 向游戏公司 Epic Games 的 GitHub 仓库提交了一个平平无奇的PR,主要涉及修改 README 文件中的几处表述性问题,以及调整 logo 尺寸事项。

image.png

比如把“can”改成“may able to”

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

image.png

Epic Games 使用 GitHub 发布游戏引擎 Unreal Engine(虚幻引擎)的源代码,但它是通过添加用户到 “EpicGames/developers ”组织的方式来授予用户对其项目的访问权限,因此与其他 GitHub 组织相比,Epic Games 成员的数量异常庞大。

更让人“绝望”的是,一些人还收到了额外的 150 封通知,因为只要有人在这个 PR 下留言评论,对这个 PR 做出回应,这个动态也会被以邮件的方式继续通知给 Epic Games 组织成员。目前,该 PR 下有 155 条评论,据统计,这种默认的“Reply All”机制导致大约有 6614 万封电子邮件被发送。

image.png

由于邮件数量太多,GitHub 邮件通知服务一度出现延迟。所以开发者们收到邮件的时间不一,即使开发者在获知此事后手动取消订阅 PR,也还是会收到在此之前积压的未发出的邮件。

Rohith 本人对此事感到十分愧疚,并在推特上道歉称自己并不知道会因此发送邮件给 40 万个成员。

image.png

有不少网友认为这次责任不在于 Rohith,Rohith 不应该拥有执行此类操作的权限,GitHub 才应该为此负责,这件事反而是一次“漏洞”的警示。

“如果不是你,其他人可能也会触发相同的通知,这也可能会产生其他副作用。你在下一次事故发生之前就指出了它,从而挽救了下一次事故,没有什么好过度担心的。”

来自 GitHub 的高级工程师 Shay Frendt 也安慰 Rohith 道:“很抱歉,我们当前的系统设计导致你陷入这种情况。我们正在努力发布补丁,以尝试中断大家陷入的反馈循环。”

目前,Rohith 提交的 PR 已被关闭,Epic Games 将组重命名为“@EpicGames/terms-of-service-signatories”,并将“@EpicGames/developers”限制成请求访问以打开 PR 的人。

微软也中招过

让 Rohith Sreedharan 更惊讶的是,这次意外被“载入史册”,作为现实案例收录进了维基百科的Email storm(电子邮件风暴)词条中。

image.png

由“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

目录
相关文章
|
11月前
|
开发工具 git
小白必须要会的Github操作 确定不进来看看?
小白必须要会的Github操作 确定不进来看看?
|
2月前
|
安全 项目管理 开发工具
探索 GitHub:现代开发者的协作平台
GitHub 是一个基于 Git 的版本控制和协作平台,广泛应用于软件开发和项目管理。它不仅提供代码托管服务,还是开发者社区和开源项目的重要平台。本文介绍了 GitHub 的核心功能(如代码托管、协作工具、CI/CD 集成等)、使用技巧(如规范化提交信息、参与开源项目等),帮助开发者提升效率和协作能力。GitHub 自2008年成立以来,已成为全球最大的代码托管平台,支持团队协作和项目管理。
|
3月前
|
Web App开发 Linux 开发工具
告别卡顿,畅享GitHub:国内开发者必看的五大加速访问与下载技巧
【8月更文挑战第4天】告别卡顿,畅享GitHub:国内开发者必看的五大加速访问与下载技巧
告别卡顿,畅享GitHub:国内开发者必看的五大加速访问与下载技巧
|
5月前
|
搜索推荐 开发者 SEO
CSDN 大规模抓取 GitHub 上的项目到 GitCode,伪造开发者主页引公愤
后续影响和发展方向 GitCode是CSDN开发的一个代码托管平台,为了快速获得搜索引擎流量,CSDN采用了惯用的手段,直接搬运大量内容进行填充。接下来,他们很可能会通过SEO农场来污染搜索引擎,以获得更多的流量。这种操作不仅对开发者极不尊重,也对整个互联网环境造成了严重的污染。 写在最后 GitCode 已经出来有挺长时间了,期间没闹出过什么问题。近期,不知道 GitCode 内部的哪位领导脑子被驴踢了,做出搬运 GitHub 的仓库来丰富自己平台内容的决定。 这种无视开发者权益、恶意搬运项目的行为,必将受到开发者社区的强烈谴责,尊重开发者的劳动成果,维护开源社区的良好氛围。开发者们也应团结
112 1
|
6月前
|
SQL 关系型数据库 Java
实时计算 Flink版操作报错之在阿里云DataHub平台上执行SQL查询GitHub新增star仓库Top 3时不显示结果,是什么原因
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
6月前
|
开发工具 git 开发者
【GitHub】如何在github上提交PR(Pull Request) + 多个pr同时提交、互不干扰
【GitHub】如何在github上提交PR(Pull Request) + 多个pr同时提交、互不干扰
917 6
|
5月前
|
数据安全/隐私保护 开发者
github 操作 异常
github 操作 异常
29 0
|
6月前
|
开发工具 git
【Github】sync fork后,意外关闭之前提交分支的pr申请 + 找回被关闭的pr请求分支中的文件
【Github】sync fork后,意外关闭之前提交分支的pr申请 + 找回被关闭的pr请求分支中的文件
90 5
|
6月前
|
网络安全 开发工具 git
web后端-GitHub文件夹上传操作
web后端-GitHub文件夹上传操作
|
6月前
|
语音技术
如何在GitHub正确提PR(Pull Requests),给喜欢的开源项目贡献代码
最好的中文TTS项目Bert-vits2更新了中文特化分支,但可能由于时间仓促,代码中存在不少的bug,作为普通用户,有的时候也想为自己喜欢的开源项目做一点点贡献,帮助作者修改一些简单的bug,那么该如何开始? 本次我们以Bert-vits2项目为例子,分享正确提交PR(Pull Requests)的方式。