1 月 31 日晚上恐怕是知名程序源码代管服务网站 GitLab 最长的一夜，因为一位工程师的疏忽造成大量资料流失，而又发现所有备份方案都无效而崩溃。 在太平洋时间的 31 日晚上，该公司陆续发布了如下一系列震惊大家的推特文： 幕后完整的故事是这样子的：当晚 GitLab 的工程师们已经花了很长时间对抗垃圾讯息的发送者（spammer），这些大量垃圾讯息已经严重影响到数据库的稳定性跟服务速度，甚至严重到锁死数据库的写入功能。 更严重的是二号数据库连复制都有困难了，跟上线的一号数据库的同步已经严重延迟，甚至拒绝连线一号数据库。线上处理的工程师里，有一位工程师的时区位于荷兰，当时荷兰已是深夜，身心俱疲的他决定把不听话的二号数据库资料全部删除再重建。 他本意是要对二号数据库服务器特定目录下 rm -rf（Unix 系的指令，不经 double check 就可以强制删除所在目录下的所有资料）指令，结果执行 1 秒或 2 秒后，猛然发现目标服务器弄错了，是正在线上服务中的一号服务器而不是有问题的二号！ 这就好像**电影里，双引擎客机要处理故障的右引擎时，却把维持飞机动力的左引擎给关掉了。 事发后的紧急处理紧急取消指令后，300GB 的资料被删到只剩下 4.5GB。而最后一个潜在可用的备份是 6 小时前手动操作的，一时之间连网站都连不进去了。根据该公司Google docs 的维护纪录在最新的讯息提到：“这个事件影响了网站数据库（包括 issue 问题和 merge requests 合并请求），但不影响 git repos（git 版本管控档案库和 wiki 服务）。” 由于不是所有资料都遗失了，所以对用户来说还是稍感安慰，但是该文件在“遇到的问题”（Problems Encountered）小节里，最后总结：“因此，换句话说，部署的 5 个不同备份／还原技术中，没有一个能可靠地工作或第一时间还原回来，我们只能从 6 小时前有效的备份还原。” 看到这句以后，彷佛全世界所有人的脸都震惊地冻结好几秒，这有点像铁达尼号的沉没是连续好几个安全机制同时失常。该公司只能坦诚地总结了这些错误 。 更糟糕的是，GitLab 去年曾经公开发表一件事：该公司本来使用的云端已经超载不够用了，要构筑和运行自己的 Ceph 云端。GitLab 的基础设施领导人 Pablo Carranza 表示，决定采用自己的基础设施“将使 GitLab 更具备高效能、一致性、可靠性，因为我们将拥有更多整体基础设施的所有权。” 回顾完 GitLab 去年的决策，再看这次发生的意外灾难最新报告，实在很尴尬。在编写本文时，GitLab 表示：
应有妥善 sop 或防呆机制GitLab 成立于 2014 年，获得 2,000 万美元的风险投资，客户包含 IBM、Macy’s、ING、NASA 、VMWare 等。在本周，这些投资者的内心恐怕比其用户更加忐忑不安。 GitLab 这事件发生以后，突显了几个议题，除了网站资料备份机制的漏洞，可能还有工程师的超时工作（导致判断失常）以及工作纪律问题：sudo rm -rf 这样最高权限不经 double check 就强制执行的指令，在使用时应该要有适当的 sop 或更好的权限防呆。这事件反映出，除软硬件设备外，人员的良善管理更为重要。 亡羊补牢为时不晚，GitLab 展现诚意以 YouTube 直播与 Twitter 将讯息公诸于网络，但是看来 GitLab 必须非常努力，才能挽回客户与投资者对该公司的信心。对其他依赖资讯科技的公司而言，相信这也是很好的借镜。 （声明：本文为“Technews科技新报”原创，如需转载请标明出处。） 拓产业研究院（TRI）专注于高新科技产业链的研究与顾问服务，是一家面向新经济的专业咨询机构。研究包括集成电路、智能终端、移动互联网、智能制造、通信技术、新能源汽车、节能环保等领域。更多关于拓的介绍，点击阅读原文。 本文转载于微信公众号: 拓产业研究院(TRI-topology)，更多微信文章请扫描关注公众号: |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
