技术文化和惨淡命运：怀念中国雅虎(2)

　　国内大部分互联网公司都是没有太多技术积累的，因为大部分产品的开发都只追求开发速度，并不会特别追求技术上的极致，就更不要提文档这种东西了。也正因为如此，从中国雅虎出来看到其它公司的知识库的时候总有不过瘾的感觉，可能也只有像 Google, 微软和 Facebook 这样的公司才会有像 Yahoo! 那样的知识库吧。在和之前一些同事吃饭聊天的时候，大家也总是会怀念那个无所不包完全开放的 Twiki ，好像少了一个忠实的朋友一样。我们由衷地尊敬那些在完成工作之余还愿意总结项目经验并花时间写 Twiki 的工程师们。

　　四、完善的流程

　　第一次参与项目开发的时候，我的 Leader 领了一个 MM 过来说：“这位是项目的 QA 负责人”，我当时愣了一下：“呃…… QA 是做什么的?” 尽管在大学里我也在实验室做过一些项目，但那些项目基本上都是我自己负责所有的事情，完全没有分工和流程的概念，所以也不知道 QA 是负责产品测试工作的。进入中国雅虎之后，我才第一次接触到商业产品的开发流程，不过由于那个时候中国雅虎已经半死不活，我也没有受到有关流程的入职培训，以至于在做了好几个项目之后才真正熟悉了完整的流程。

　　中国雅虎的开发流程沿袭了 Yahoo! 的开发流程，乍看之下很平常，对于已经熟悉的工程师来说还显得枯燥，但后来我特别留心了这套流程之后，非常惊奇于它的严谨和高效，所以这里要详细说明一下。Yahoo! 的内部生产线分为三个相互独立的环境：开发环境、测试环境和生产环境(即线上环境)。这三个环境虽然独立，但它们的配置都会尽量保持一致，这样就可以保证开发完成的产品不会因为环境不同而出现问题。在开发的时候，我们会在开发环境中搭建虚拟环境，开发完毕之后开发工程师会自己在虚拟环境里面测试，保证没有大的问题，然后就会把所有相关文件打包上传到雅虎全球统一放置产品包的地方。上传完毕之后，就会发邮件通知 QA 部门相关人员，邮件内容里面要写明产品在测试环境的部署步骤：需要安装哪些包、是否需要修改数据库等等。然后 QA 就会开始测试，如果发现 BUG 就会写到 bugzilla/' target='_blank'>Bugzilla 中，指派给相应的开发工程师，开发工程师就会在开发环境中定位BUG并修正，修正一些BUG之后就会再次打包升级产品的版本，然后QA 会将新的软件包部署到测试环境验证之前的 BUG 并报告新的 BUG 。整个测试过程中可能要发布好多个版本，直到所有 BUG 被修正为止。修正完毕所有的 BUG 之后，开发工程师就会填写上线申请，Ops 看到申请之后就会安排一个时间把产品部署到生产环境。一般来说，生产环境不止会有一台机器，所以 Ops 会先从生产环境摘下一台机器部署，部署完毕之后会告知 QA 和开发工程师，然后 QA 和开发工程师就会修改 Hosts 文件，配置域名指向那台机器进行线上的测试，如果测试没有问题，那么就会把软件包部署到生产环境中所有的机器上，完成上线;否则就进行回滚，取消这次上线，也不会影响到线上的用户。

　　整个流程大概就是这样，但是要特别注意的是以下几点：1. 开发工程师只能接触开发环境。他所能做的就是在开发环境中开发、改 BUG 和打包上传。如果他去测试环境中修改 BUG，就很有可能忘记修改开发环境中的相应代码，这可能会导致产品测试通过但是上线之后却发现大的问题。 2. 产品“封版”之后就不可以做任何改动，如果有改动，即使只改动了一点所有功能也要重新测试一遍。所有的 BUG 都修改完毕之后的那个版本就会进行“封版”，那就标志着这个产品随时可以准备上线了。如果真的发现了新的 BUG 要修改的话，那么修改之后就需要重新打包重新走一遍完整的测试流程，只有这样才能够保证就算修改代码过程中引入了新的 BUG 也不会被遗漏。 3. 上线手册要详细。开发工程师要详细写明每一个步骤，不只是说明性的文字，还要把具体的安装和修改命令完整地放上去，如果写得好的话，那么 Ops 的同事只需要把上线手册里面的命令逐行复制到服务器上运行就可以完成上线。

　　这样的流程有什么好处呢? 首先，它最大地降低了上线风险。因为开发工程师不能接触到测试环境，只能打包让QA测试，所以完整经过测试的产品上线之后基本不会有什么问题，况且上线的时候我们也要先部署到一台机器上进行测试之后才会决定是否上线，即使上线不成功也可以在不影响用户的情况下回滚。中国雅虎的上线极少会出现问题，很多时候我们上线到半夜只是因为那个时间段用户访问量最小，而不是说焦头烂额地忙活几个小时一直到半夜才上线成功。其次，它使得各个部门职责分明。开发工程师和 QA 通过 Bugzilla 沟通，和 Ops 通过上线手册沟通，因为沟通渠道唯一而且清晰，所以就可以完全责任到人，出了问题也很容易定位到具体环节。比如说，如果产品测试通过之后在上线的时候出现了问题，那么基本就可以确定是 Ops 操作失误或者上线手册没有写好。职责分明之后很多事情也变得有条理，大家就可以各司其职、专注本职工作并且合作愉快，开会的时候也可以明确知道需要哪些人参加。

　　完善、清晰的流程从根本上解决了一些问题，创建了一个非常好的环境，这样我们就可以把心思都放在如何开发和测试上面，而不用担心诸如“如何上线才能不出错”等琐碎的事情。所以尽管中国雅虎的高层那么不靠谱，我工作得还是很开心，因为这个流程保证了管理层再怎么乱开发也不会乱。记得那时候很喜欢改 BUG ，有时候改得兴起会把之前版本遗留的 miss BUG 一并改掉，加班也是颇有兴致，不是很能明白为什么网上大部分程序员讨厌加班讨厌得要死。现在我明白了。

　　五、自动化工具

　　工欲善其事，必先利其器。如果没有那么多好用的自动化工具，那么 Yahoo! 的流程就不可能如此完善。Yahoo! 内部有很多非常好用的工具，而且这些工具都有非常齐全的文档，也可以在 Twiki 上找到不少相关资料。这些工具之所以在 Yahoo! 会起到那么大的作用，是因为 Yahoo! 全球所有的技术团队都在使用它们，Yahoo! 所有的服务器上也是默认安装了这些工具。这些工具就形成了一套全球 Yahoo! 工程师通用的话语体系，可以想象它们帮助 Yahoo! 节省了多少沟通成本。

　　由于考虑到服务器的安全问题，Yahoo! 的这些工具的使用方法是对外保密的，这里我只简单说一下 Yinst 这款工具的强大。假如要把软件包 example_1_1_0.tar.gz 部署到 a1.yahoo.com ~ a10.yahoo.com ，那么只需要下面这样一行命令：

原文转自：http://blogread.cn/it/article/2703?f=wb