ZD至顶网安全频道 02月03日 综合消息:源码托管平台GitLab因运维人员误操作导致300G数据被删除的教训值得深思,即使工作人员努力恢复,但仍丢失了6小时的部分数据。
GitLab称最终受影响的用户不到1%,从结果看来,虽然不像事故刚发生时人们预期的网站发生灾难性事故那样,但它产生的影响并不小,所带来的教训也足够深。
这是一起由IT工程师人为原因引发的事故,作为同行,从网络上看,不少程序员、IT运维人员进行了反思,并对Gitlab的数据库误删事故进行了总结。
网友“Li Gong”总结了这次事故中GitLab犯的一系列错误:
1、在深夜做高风险操作
事件的起因是GitLab遭到攻击后,一位工程师加班到深夜维护线上环境。因为遇到了种种常规脚本没能解决的问题,不得不进行大量人工操作,于是在精力不济后出现致命失误,准备从 db1 同步到 db2 时错误的删除了 db1 的数据。
2、部分备份脚本/设置没有定期维护
GitLab 的 PostGreSQL 本地备份和 Amazon S3 备份都没有正常工作。
其中 PostGreSQL 本地备份设置在数据库版本升级后失效了,但没有人注意到。
其它备份脚本也处于散落各处,长期无人维护的状态。
3、部分备份方案没有覆盖到所有数据类型
Azure 提供了磁盘快照服务,但 GitLab 的 数据库服务器并没有使用,只在 NFS 服务器上使用了。
4、部分备份方案没有保留完整数据
GitLab 在 Staging 环境上有一份6小时以前的数据,但其中没有保留 Webhook(STG 环境不应产生真实的 Webhook 行为)。实际上 Staging 环境本就不应该承担备份的责任,但这是 GitLab 眼下能找到的最完整历史数据了。后来他们在其它的备份中补回了 Webhook 的数据。
5、备份流程没有 Monitoring 和 Alert
因为没有 Monitoring 和 Alert,以上这些安全隐患长期没有人发现和注意。
6、备份频率不足
GitLab 的各种备份方案都是每天运行一次,从这次事件来看,对于他们来说可能还是不够。
7、备份不能正确恢复/需要太长时间
GitLab 的 LVM 快照因为某些原因,没能正确恢复成功。
从 Staging 环境恢复到 Production 环境的过程中,因为跨数据中心的网速以及 Staging 环境的磁盘速度等原因,备份数据在10个小时后还只传了一半,大大拖延了恢复进程。
8、没有正确的设置维护 PostGreSQL
事故发生后一些第三方评论指出(参见官方事故报告附录),GitLab 没有正确的配置和使用 PostGreSQL,也是这次事故升级的部分原因。
网友“王子嬴”给出了保障数据安全的5个策略建议:
1. 数据至少 3 个节点实时同步
2. 额外节点做延时 1 小时的半实时同步
3. 每天全量备份
4. 全量备份保存在两个相隔 30 公里以上的机房
5. 数据相关服务动态伸缩实例时,基础数据从全量备份副本恢复,保证备份副本可被正常使用
以保证不管是天灾还是人祸都可恢复。
Coolshell博主“左耳朵耗子”也进行了解读,此处摘取他对于备份的思考:
一个系统是需要做数据备份的,但是,你会发现,GitLab这个事中,就算所有的备份都可用,也不可避免地会有数据的丢失,或是也会有很多问题。理由如下:
备份通常来说都是周期性的,所以,如果你的数据丢失了,从你最近的备份恢复数据里,从备份时间到故障时间的数据都丢失了。
备份的数据会有版本不兼容的问题。比如,在你上次备份数据到故障期间,你对数据的scheme做了一次改动,或是你对数据做了一些调整,那么,你备份的数据就会和你线上的程序出现不兼容的情况。
有一些公司或是银行有灾备的数据中心,但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候,你就会发现,各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴,宁夏银行7月系统瘫痪最新解析》。
所以,在灾难来临的时候,你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作,但也会导致数据丢失,而且可能长期不用的备份系统很难恢复(比如应用、工具、数据的版本不兼容等问题)。
所以说,如果你要让你的备份系统随时都可以用,那么你就要让它随时都Live着,而随时都Live着的多结点系统,基本上就是一个分布式的高可用的系统。因为,数据丢失的原因有很多种,比如掉电、磁盘损坏、中病毒等等,而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作,都不管用,这个时候,你不得不用更好的技术去设计出一个高可用的系统!别无它法。
很多网友贡献了他们的智慧,虽然此类事件并不会终结,并且未来肯定会再发生,例如近期《炉石传说》数据丢失回档要比GitLab差得多。但每一次事件带来的教训和事后的经验总结值得好好思考,以降低同类事件发生概率。
除了网友们贡献的智慧,GitLab也对数据恢复的过程在YouTube进行了直播,引发超过33万网友围观,作为IT程序员的你不妨看一看,从中你肯定会总结发现一些非常有价值的经验。我们进行了本地视频上传,不用翻墙。
本文引用的网友观点如有侵权,请联系删除。
好文章,需要你的鼓励
当前企业面临引入AI的机遇与挑战。管理层需要了解机器学习算法基础,包括线性回归、神经网络等核心技术。专家建议从小规模试点开始,优先选择高影响用例,投资数据治理,提升员工技能。对于影子IT现象,应将其视为机会而非问题,建立治理流程将有效工具正式化。成功的AI采用需要明确目标、跨部门协作、变革管理和持续学习社区建设。
这项由东京科学技术大学等机构联合发布的研究提出了UMoE架构,通过重新设计注意力机制,实现了注意力层和前馈网络层的专家参数共享。该方法在多个数据集上显著优于现有的MoE方法,同时保持了较低的计算开销,为大语言模型的高效扩展提供了新思路。
美国垃圾收集行业2024年创收690亿美元,近18万辆垃圾车每周运营六至七天,每日停靠超千次。设备故障成为行业最大隐性成本,每辆车年均故障费用超5000美元。AI技术通过实时监控传感器数据,能提前数周预测故障,优化零部件库存管理,减少重复维修。车队报告显示,预测性维护每辆车年节省高达2500美元,显著提升运营效率和服务可靠性。
小米团队开发的MiMo-7B模型证明了AI领域"小而精"路线的可行性。这个仅有70亿参数的模型通过创新的预训练数据处理、三阶段训练策略和强化学习优化,在数学推理和编程任务上超越了320亿参数的大模型,甚至在某些指标上击败OpenAI o1-mini。研究团队还开发了高效的训练基础设施,将训练速度提升2.29倍。该成果已完全开源,为AI民主化发展提供了新思路。