Loading
0

从 gitlab 事件中吸取的教训

题注:这是一篇去年的文章,今早看到 gitlab 运维人员愚蠢地 rm -rf, 心有戚戚焉,故而重发这篇文章,供大家参考。

这两天不是很太平,程序圆媛猿亲们出门前最好拜拜祖师爷 Ada,然后给八阿哥上柱香。

周一早上,我钟爱的一个在线绘图工具 gliffy 挂了。我发现这个问题是因为当天中午我有一个 tech talk,有两张图还没截出来放在 slides 里,结果打开它的时候才发现是这么个状态:

起初我还没在意,结果昨天发现还打不开,知道事情大了。一开始我猜想是黑客攻击,后来看了 hacker news 上的讨论,才知道一个可怜的 sysadmin(好吧,姑且认为他也是个程序员吧,谁叫 dev ops 不分家呢)误操作,删除了 production database,然后整个系统就果断罢工了。gliffy 的技术团队日以继夜地试着恢复他们的数据,可是直到今天,还没有恢复完成。你要是 CEO,你想不想废了那个可恶的家伙?

然后,昨天晚上,朋友圈开始狂转一篇文章:「程序员的bug导致了天大的损失,要枪毙程序员么?」大意是一个坑爹的证券交易员的乌龙导致交易软件里一个「头上有犄角,身后有尾巴」的八阿哥跳出来大唱「我就是不撤单,我就是不撤单」,然后一天之内几百亿美金就被这个八阿哥给吃了。你要是证券公司的老总,你想不想做了那个放出来八阿哥的程序员?

。。。

你看看医生多悲催,别说医疗事故了,没有医活也许本就无医可救的病人,运气好的,被病人家属说些诛心的话;运气不好,被医闹公然折腾,或者在冷僻处被拍板砖。如果程序员每写出一百个 bug 就要被诛心的话,恐怕没有程序员活得过三十。

还好,这个世界是个对程序员友好的世界,程序员不哭。

当 gliffy 事件持续发酵时,hacker news 里满满地都是正能量 -- 大多数人的观点是:作为一个程序员,你如果没有「日了狗了」的高光时刻,你都不好意思给自己挂个资深的抬头。有个哥们这么说:

My very first job - ~25 years ago.

Destroyed the production payroll database for a customer with a bug in a shell .

No problem - they had 3 backup tapes.

First tape - read fails.

Second tape - read fails.

Third tape - worked.... (very nervous at this point).

还有个更绝:

I was testing disaster recovery for the database cluster I was managing. Spun up new instances on AWS, pulled down production data, created various disasters, tested recovery.

Surprisingly it all seemed to work well. These disaster recovery steps weren't heavily tested before. Brilliant! I went to shut down the AWS instances. Kill DB group. Wait. Wait... The DB group? Wasn't it DB-test group...

I'd just killed all the production databases. And the streaming replicas. And... everything... All at the busiest time of day for our site. Panic arose in my chest. Eyes glazed over. It's one thing to test disaster recovery when it doesn't matter, but when it suddenly does matter... I turned to the disaster recovery code I'd just been testing. I was reasonably sure it all worked... Reasonably...

Less than five minutes later, I'd spun up a brand new database cluster. The only loss was a minute or two of user transactions, which for our site wasn't too problematic.

My friends joked later that at least we now knew for sure that disaster recovery worked in production...

Lesson: When testing disaster recovery, ensure you're not actually creating a disaster in production.

还有很多温情的留言,说如果这个可怜的哥们(姐们)被炒鱿鱼了,他们愿意立刻雇佣他(她),理由很简单:唯有经历刻骨铭心,才能换来成熟。

程序君也干过误删数据库的蠢事,作为一个教训,我把它写进了我的『途客圈创业记』里面。

Murphy's law 告诉我们:"Anything that can go wrong, will go wrong." 当你运营着一个系统,服务器会崩溃,数据库会损坏,硬盘会失效,... 不要相信所谓的 MTBF(Mean time between failure),一切一切的小概率事件,只要发生在你身上一次,就是灾难。

作为事后诸葛亮,我们想想,遇到这样的灾难该怎么处理?

首先 我们要有一个详细的灾难处理流程(Disaster Recover Process,以下简称DRP)。把所有可能发生的事情做个攻防演练:如果发生其中的一个或者多个意外情况,你该怎么处理?

比如说:黑客攻击了你的服务器,删除了所有的备份,怎么恢复服务器的运行?

你的 DRP 可能是:多级备份,数据除了本地备份外,还备份到一个权限更高的,远程的,物理上隔离的地方。

如果你使用 AWS,这个翻译过来就是:备份的账号和生产环境的账号分开,生产环境在自己的账号下的 S3(或者其他服务下)备份数据以外,还要在备份账号下的 S3 备份数据。这样,当黑客获取了生产环境的 aws 账号的最高访问权限,即便删除一切,只要备份账号还健在,一切还能救过来。

仅仅有 DRP 是不够的,我们还要确保 DRP 随时可用。这就是第二个要点:像测试你的生产环境一样测试你的灾难处理流程,使其随时可用。这一点是被绝大多数人忽略的。你如果看 gliffy 的更新:

3/22/16 7:24am PST: Unfortunately one of the restore processes failed because it used significantly more disk space than we anticipated. The other restore processes have been configured with more disk space to reduce the chance of this problem happening again.

分页阅读: 1 2
【声明】:8090安全小组门户(https://www.8090-sec.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们:邮箱hack@ddos.kim,我们会在最短的时间内进行处理。