Elasticsearch 开源仓库 404，7 万多 star 一夜清零

运维 · 公众号 · 运维 · 2024-10-31 12:28

正文

来自：OSC开源社区

Elasticsearch 团队公布了此次 “GitHub 仓库归零” 事故的具体过程，万万没想到居然是内部人员操作失误 —— 将原本的公开仓库设置成了 “私有”。

事件概述如下：

问题发现：2024 年 10 月 29 日 12:28 UTC，Elastic 公司发现其在 GitHub 上的一些公开代码仓库暂时无法访问。
问题识别：经过调查，确认问题是由于内部变更操作导致，Elastic 公司在 GitHub 组织下的某些公开 git 仓库被错误地标记为私有。
紧急响应：Elastic 的团队开始紧急工作，以恢复这些受影响的仓库为公开状态。
部分恢复：在 12:51 UTC 至 15:09 UTC 期间，除了 Kibana 仓库外，所有其他仓库都被改回为公开状态，并且它们的分支（forks）正在恢复中。
持续沟通：Elastic 公司持续更新状态，表示正在等待 GitHub 支持团队对 Kibana 仓库的进一步操作，预计可能需要几个小时或更长时间。
完全解决：18:39 UTC，Elastic 宣布所有受影响的仓库都已恢复为公开状态，它们的分支 (forks) 也已恢复。（来自：OSC开源社区）

观点 1：误操作啊，会不会祭天？
观点 2：没有误操作的可能。还是想在一个版本上取消开源的版本。
观点 3：标题: 你在工作中都捅过什么重大的娄子
观点 4：es 不需要 star
观点 5：stars 就是无法恢复了，之前也有著名项目也是相同的操作，最终 starts 只能慢慢回
观点 6：不可能误操作，设置 private 的时候需要重复输入一次仓库名称的
观点 7：es 这种级别的项目，star 数据已经用处不大了吧
观点 8：他们已经完全走商业的 saas 路。所以想用的人都要付费了。
观点 9：这么点星，弃用
观点 10：行为艺术而已不必太过担忧
观点 11：github 公有库改成私有库，就会清空 star。不过在操作的时候，会上手动输入当前 star 数进行确认。gitee 倒是不会清。
观点 12：httpie 当时就这么干了，这会星星已经涨回来了