专栏名称: 数据分析与开发
伯乐在线旗下账号,分享数据库相关技术文章、教程和工具,另外还包括数据库相关的工作。偶尔也谈谈程序员人生 :)
目录
相关文章推荐
数据分析与开发  ·  低级失误导致 Elasticsearch ... ·  2 天前  
数据分析与开发  ·  离谱!裁员裁出新高度了。。 ·  昨天  
51好读  ›  专栏  ›  数据分析与开发

低级失误导致 Elasticsearch 仓库 404,7万多 star 一夜清空,网友:只是手滑了?!

数据分析与开发  · 公众号  · 数据库  · 2024-11-03 10:34

正文

转自:InfoQ - 冬梅

顶级开源搜索引擎 GitHub 仓库突发 404 

近日,Hacker News 上一则消息引来众多开发者围观,因为周二晚间,有开发者发现全球顶级开源搜索引擎 Elasticsearch(简称 ES)的 GitHub 仓库突发 404,star 数从原来的 7 万多暴跌至 200 多,目前才恢复到 2.4 万多。

Elasticsearch 是一个开源的分布式、高度可扩展的全文搜索和分析引擎。它能够快速、近乎实时的存储、搜索和分析大量数据。适用于包括文本、数字、地理空间、结构化和非结构化数据等在内的所有类型数据。它通常为具有复杂搜索功能的应用提供底层搜索技术。

团队公开法发文解释了此次 404 事件的过程及原因。据他们称,造成此次事件的原因是内部人员操作失误——将原本的公开仓库设置成了“私有”。事件过程详情如下:

2024 年 10 月 29 日 12:28 UTC,发现问题:团队已经获悉某些公共代码仓库暂时不可用,目前正在努力解决此问题。


2024 年 10 月 29 日 12:51 UTC,问题更新:作为内部变更任务的一部分,Elastic 在 GitHub 组织下托管的某些公共 git 代码仓库被标记为私有,因此在尝试访问这些仓库时可能被提示错误。我们团队正在紧急恢复这些代码仓库。


2024 年 10 月 29 日 15:09 UTC,进一步说明问题:我们团队正在执行恢复流程,将受影响的 git 代码仓库恢复至公共状态,补救措施也将很快开启。此次事件源自内部变更任务,其中 Elastic 在 GitHub 组织下托管的部分公共 git 代码仓库被标记为私有,因此在尝试访问这些仓库时可能被提示错误。


2024 年 10 月 29 日 16:06 UTC,继续更新说明:除 Kibana 之外的所有代码仓库均已改回公共状态。GitHub 正对这些代码仓库的分叉进行恢复。我们正等待 GitHub Support 对 Kibana 代码仓库的进一步修复。

2024 年 10 月 29 日 17:07 UTC,持续更新:除 Kibana 之外的所有代码仓库均已改回公共状态,且各代码仓库的分叉已经恢复完成。我们正等待 GitHub Support 对 Kibana 代码仓库的进一步修复。


2024 年 10 月 29 日 17:59 UTC,继续保持更新:如前所述,除 Kibana 之外的所有代码仓库均已改回公共,且相关分叉已经恢复。我们正等待 GitHub Support 支持团队对 Kibana 代码仓库的进一步修复,但预计还需要几个小时(或更长时间)才能将其改回公共。


2024 年 10 月 29 日 18:39 UTC,问题已解决。所有受影响的代码仓库均已开放,且相关分叉也已恢复。


网友怎么看?

此次事件在社区中产生了不小的影响,尤其是 star 数从大几万突然归零确实让人有些震惊。有网友表示,自己刚刚检查了一下,仓库里只有“9 个分叉”和“194 star”,不知道 GitHub 到底有没有办法能撤销这一操作。

对于此次事故更详细的原因,有网友猜测,Elastic 使用的是针对 GitHub 的 Terraform 提供程序,并且他们以自动化的方式将仓库标记为私有,而反向 API 操作则无法以相同方式执行。

也有网友给 Elasticsearch 支了一招:“我不知道是否真的是 Terraform 的问题,但如果是的话,其实很容易通过回滚 IaC(基础设施即代码)Terraform 本身,或者甚至从之前的状态文件中恢复。”

还有人猜测,是 Elasticsearch 不小心遗漏了密钥然后采取的补救措施:“我敢打赌,肯定是有人不小心推送了一条密钥,之后又把仓库设为私有想要尽量减少损失……”Elasticsearch 称“团队正在努力恢复受影响的 git 仓库,将其恢复至公共状态”,对此有网友质疑为何 Elasticsearch 没有直接设回公共,难道里面有什么别的猫腻?

也有用户认为,这是个严重错误,甚至会影响到仓库的排名。“此仓库的 star 和观察者将被永久删除,这将影响到代码仓库的排名。”

也有人认为,这只是内部人员的一次低级错误,并没有那么多“猫腻”。

此次事件后,也有网友给出了规避此类误操作的办法。“虽然事件已经得到恢复,但我想补充的是,我们一直为自己使用的仓库保存着私有副本,而且每天都通过自动化程序进行提取。多年来从没出过问题,大家也可以试试。”

参考链接:

https://status.elastic.co/incidents/9mmlp98klxm1

https://news.ycombinator.com/item?id=41983932


推荐阅读  点击标题可跳转

1、字节回应大模型训练被实习生攻击

2、千万级数据的全表 update 正确姿势

3、京东:MySQL 中的 distinct 和 group by 哪个效率更高?太刁钻!