微信号:infoqchina

介绍:有内容的技术社区媒体

Etsy工程师:我们一天可以做70次部署!

2013-03-21 16:26 InfoQ

Etsy使用Git做代码管理,平均每天提交的更新数量在30次左右,有时甚至达到70个。在如此高频率提交代码的情况下,他们如何进行代码审查?如何在每次更新之后监控系统性能?如何处理故障?


在本次访谈中,Sam Haskins将对以上问题做出解答,分享他们的DevOps经验。Sam Haskins目前属于Etsy的核心平台团队,该团队一共有10~15人,整体负责服务器及系统层与应用层的接口,为上层开发特性的工程师们提供服务。Sam于2010年中加入Etsy,他现在主要负责数据库接入层,也在web框架上做一些东西。核心平台团队的其他成员还负责开发图片存储系统、异步任务管理等功能。Sam毕业于卡内基梅隆大学的数学系。


InfoQ:第一个问题是关于部署系统的。你们使用哪些工具?


Sam:我们使用Git做代码版本管理,使用Deployinator(我们为自己开发的一个工具)从Git中拿东西出来,并把它放到所有的服务器上。基本上就是文件复制工作,没有什么特别的。另外,我们使用Chef做配置管理。就这些了。实际上我们用GitHub。我们有一个内部的GitHub来管理代码。


关于代码审计流程,实际上我们没有很多正式的检查。只要你的代码能编译,能运行,你就可以放到代码库上,不需要审计。但是,我们鼓励大家做代码复查,而且大家经常这么做。代码复查通常是这样的——你只要把你的补丁发给别人看,他们看过后给你一些点评。大多数人在推送代码到代码库前都会这么做。


InfoQ:有QA吗?


Sam: 没有。我们没有传统意义上的QA。因为我们每次的提交都很小,所以发现哪些代码破坏了系统通常是相当容易的。当然,也有一些人的工作有点儿像QA,他们的工作就是试着破坏我们的系统,然后让我们知道哪些东西坏了。我们部署做得很多,一天部署50次挺平常的,有时候会更多。在部署前后做全面的测试是不可能的,根本没有足够的时间。但是我们有自动化测试,和代码审查等等,而且我们每次的变更都很小,所以,我们认为我们并不需要有一个大规模的正式的QA过程。


InfoQ:由于你们每天部署这么多次,那么你们通常在一天中的什么时间部署?你是部署后,观察几分钟,然后再部署另一次吗?


Sam:是的,我们有很多度量项,可能成千上万吧。所以 每次部署后,除了要监控你的变更是否起作用了,我们还有一个标准的部署指示仪表盘,你需要关注。那上面有一堆图表,你要看着它,并确保仪表盘上的指标没有异常。


我们还有一个工具,用来读实时日志,你也要看看那个东西。假如有些东西不正常,那你就需要修复它。但只需要几分钟就行,通常是一两分钟。但我要看更多一些的图表数据。 只要没有什么问题出现,并且你认为你的修改正常工作了,那就轮到下一组啦。


InfoQ:当部署时,你是先把它部署到测试环境上吗?


Sam:有一个前提,在你部署之前,你已经自行测试过它了,所以我们是直接部署的。不过,的确也可以说我们已经在测试环境上部署过了,因为我们的试运行环境也是我们的生产环境,是同一个环境,只是版本高一点儿,而且用户不可能访问到这些服务器,只有我们才能访问。


因此,当部署时,首先会放到试运行环境,然后CI(持续集成服务器)会运行测试,是单元测试。顺便说一下,我们使用的是Jenkins。同时,你可以访问试运行环境,Jenkins运行一系列的测试。之后,一旦推送代码的人认为试运行环境上的功能没有问题,他们已经测试过他们的变更,并认为这些变更运行正确的话,那么只是Jenkins运行完(通常总共需要5分钟),就可以推送到生产环境了。


InfoQ:能讲一下最近的一次故障吗?


Sam:好。比较典型的情况是,我们只会遇到一些很小的问题。比如,有人正在修改一个页面,而此时我们网站上的一个卖家正在修改他有多少东西可以卖。我并不能说这是一个现在正在发生的案例,但是,它的确与我们看到的小故障类似。这个开发人员修改的恰好是这个页面,那么卖家可能就会看到一个错误,但这并不会耽误大家在网站上卖东西。这时我们会认为,问题并不大。这个开发人员去查看一下,然后修复它就行了。通常由于变更很小,所以直接修复,然后推送部署就行了。但要强调的是,如果问题比较严重,那就会回滚。


最近就发生了一个非常严重的问题:我们在数据库中使用完整的IDs,而这些IDs不是自增的。我们没有让数据库来做这种ID自增,因为我们所有的数据库都是双主方式(two masters)的,即master-master。所以无法使用自增,因为你不知道哪个master是最近一次做自增操作的。所以我们有另外一个服务器,由它来专门提供这些自增数字。这个服务器也有两个。其中一个只产生奇数,而另一个只产生偶数。 这就是用户ID帐户的来源。


几个月前,这个服务器的数字超过了2^31,所以溢出了32位的整数列,但这也不是太大的问题,因为你可以把它保存在一个64位的列中。然而,在代码中的一些地方并没有这么做。但是,大家并没有意识到为什么ID突然出现了64位。因此,当ID太大时,一些相关的特性就无法工作了。


这些地方的代码无法得到合理的ID,但仍旧试图把它保存到数据库上,但数据库无法保存它。当这个问题发生时,我们立刻要求大家不要再推送代码了。我们只花了大约一分钟就找到了这个故障的原因,因为在日志里有很多错误信息,这些信息中能看到那些数字。如果之前你看到过这样的数字,你会就发现这个问题。你能想像得到当看到这样的数字时,那种不祥的感觉。


我们看到后,我们就立刻停止推送,是我们的团队(core platform team)发现它的。尽管我们知道这是一个严重的问题,但我们并不知道有多少数据库表使用了它,因为没有地方可以看到这样的信息。我们召集大家,包括一些运维工程师和我们团队的一些人,到会议里来讨论如何处理这个问题。最后决定相看所有的表,看看到底哪些数据库表的列宽不足。


在数据库里,代码中,以及写的schemas中都可能有相关的信息。所以我们只能查看所有的代码,来判断有多少schemas中存在这个问题。有些只是代码中有问题,有些只是在数据库中有问题。有些地方则是两方面都有问题。同时,其他人来判断哪些特性受到了牵连。我们从错误日志中有可能发现这些受牵连的特性,也可能从图表上发现。只要发现了,就可以找以相应的配置文件,把这些特性关掉。


一旦我们修改好所有的地方,我们就可以在数据库上运行这些变更,将那些字段改成64位,再把关掉的特性开关打开,然后马上监控,看哪些数据还会出异常。整个过程只持续了几个小时,而且只有几个比较小的特性受到了影响。但直到把全部问题都修复了,我们才能知道到底有多少特性受到了影响。因为很多影响不是显而易见的。


点击“阅读原文”查看更多内容并吐槽吧。

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 【大宝】他用7人团队,服务包括优衣库在内的30多家知名企业的秘籍竟然是... 以人为鉴:甲骨文公司云时代的明星工程师 淘宝技术部世界杯算法大赛赛况 有云,有花,我们的世界将会更精彩 走入Redis的世界