Elastic Blog - Elasticsearch, Kibana, and ELK Stack
·
无星：我们如何意外地使最受欢迎的GitHub仓库消失
💡
原文英文，约2500词，阅读约需9分钟。
📝
内容提要
2024年10月，Elastic意外将其热门GitHub公共仓库转为私有，导致客户遭遇严重故障。此事件源于内部工具的自动化变更未能验证状态。Elastic已改进仓库管理和安全策略，以防止类似事件重演。
🎯
关键要点
- 2024年10月，Elastic意外将其热门GitHub公共仓库转为私有，导致客户遭遇严重故障。
- 事件源于内部工具的自动化变更未能验证状态，导致公共仓库被错误标记为私有。
- Elastic在GitHub上有约3000个仓库，客户包括小型企业和情报机构，期望高水平的供应链安全。
- Elastic的仓库有三种可见性：公共、内部和私有，内部仓库的使用在2023年中期被弃用。
- 迁移计划中，Elastic收集了内部仓库的列表，并未能有效验证仓库的实际可见性。
- 执行脚本后，63个公共仓库被错误地转为私有，导致自动构建管道失败。
- Elastic的事件管理流程有效地处理了此次重大故障，迅速创建了事件频道并升级为高严重性事件。
- 与GitHub的合作帮助恢复了被转为私有的仓库，63个受影响的仓库在七小时内恢复为公共状态。
- 事件的根本原因包括一次性更改过多和对仓库列表的假设，导致未能验证实际状态。
- Elastic采取了多项措施防止类似事件重演，包括限制修改仓库可见性的权限和去中心化的变更流程。
- 团队在事件处理中的支持和无责文化对恢复过程产生了积极影响，展现了团队的凝聚力。
❓
延伸问答
Elastic是如何意外将其GitHub公共仓库转为私有的？
Elastic在2024年10月通过内部工具的自动化变更，未能验证仓库的实际状态，导致63个公共仓库被错误标记为私有。
此次事件对Elastic的客户造成了什么影响？
事件导致自动构建管道失败，影响了Elastic及其客户的操作，造成了严重故障。
Elastic采取了哪些措施来防止类似事件重演？
Elastic限制了修改仓库可见性的权限，并去中心化了变更流程，以减少错误发生的可能性。
Elastic在事件管理过程中采取了哪些步骤？
Elastic迅速创建了事件频道，并在10分钟内将事件升级为高严重性事件，确保了有效的沟通和响应。
Elastic的GitHub仓库有哪几种可见性？
Elastic的GitHub仓库有三种可见性：公共、内部和私有。
Elastic在此次事件中与GitHub的合作有什么重要性？
与GitHub的合作帮助Elastic在七小时内恢复了被转为私有的63个仓库，并恢复了其公共状态。
➡️
