像Facebook这样一个网站，每周发布自然是分阶段进行的，首先是H1，即部署到仅有内部访问的服务器上，进行最后的测试，很多公司也称其为“预发布”；随后是H2，部署到几千台服务器上，开放给一小部分用户；如果H2阶段没有发现问题，则进入H3，部署到全部服务器上。 如果在这个过程中发现问题，工程师会立即进行修复，随后重新开始分阶段的部署。当然，也可以选择回滚代码，有两种回滚方式——常见的是回滚某个变更及其依赖的文件，另一种则是回滚整个二进制包。 Facebook在四个不同的地理位置分布了大量的服务器，整个发布的包大约有1.5G，一般需要20分钟来完成整个分发。为了实现这一点，分发过程中分发使用了BitTorrent，分发时也会考虑到机架和集群的亲缘性。自从Twitter开源了他们的基于BitTorrent的发布方案Murder后，通过BitTorrent进行发布已然成为了业内的标配。 在发布时，与变更相关的开发者必须在线，发布工程师会通过IRC机器人进行确认，如果人不在，那么他的变更会被回滚。这样保证了问题能够在上线之初就被快速发现并修复，当然，想在这么大的一个系统里及时发现一些问题有时也是很困难的，所以Facebook会结合内部工具Claspin和外部的信息源（比如Twitter）持续地监控系统的健康状态。 通过Gatekeeper系统，工程师们可以方便地控制多少用户能够访问特定的新功能，筛选的条件可以是地区，也可以是年龄，在遇到问题是也能迅速关闭某个功能的入口。在Gatekeeper的帮助下，工程师们能方便地进行A/B测试，藉此迅速收集用户的真实体验，对产品做出调整。不要忘了，在Facebook，是工程师来选择自己做什么的，那么工程师们肯定是选择把东西做出来，看看用户的反应，而不是坐在会议室里和一堆人开会去猜测用户想要什么。 Kent Beck在文中表示：仅有方法论和工具是远远不够的，因为它们总是会被误用。所以，拥有鼓励个人责任感的企业文化是很重要的。 现在，Facebook有大约1000名开发工程师，仅有3名发布工程师，没有独立的测试工程师。每位工程师都可以看到全部的代码，并且能提交补丁，或者提交详细的问题描述。工程师们需要自己编写详尽的单元测试，他们的代码还要通过所有的回归测试，并能支持后续的各种运维工作。 除了要对自己的代码负责，他们还要面对各种巨大的挑战，往往要针对多种解决方案进行大量试验。比如，当时为了解决PHP的性能问题，有3个不同的方案同时在进行开发，当某个方案的负责人发现另一个方案更好时，他们就会停下来；最后HipHop胜出了，但另两组人的精力也没白费，他们提供了重要的备份能力。 在文章的最后，还提到了Facebook的新兵训练营制度，关于这一点，Facebook的早期员工王淮在他的《调教你的新工程师 – 谈新兵训练营》中做了详细的描述。 关于Facebook，有很多值得深入学习和探讨的地方，比如他们的工程师文化，比如上文提到的新兵训练营。不知您在看了Kent Beck的文章之后有何感想，能否和InfoQ的读者们一同分享一下呢。 |
