初创公司技术困境：弹性部署与详尽测试(2)

测试环境只包含供内部使用的集群。出故障时只影响公司内部员工。准生产环境包含面向外部大众用户项目的搜索集群。生产环境包含我们客户的集群。安全环境包含我们最重要的 SLA 客户的集群。根据部署策略，我们通过使用多个不同的环境来降低风险。也就是说，我们会先在对客户影响最小的集群上进行部署。

除了不同的环境，我们还利用了三份复制这个特性，制定了如下的 12 步部署流程：

先部署到测试环境的所有三个节点上；部署到准生产环境的第一个节点上，再部署到生产环境的第一个节点，再部署到安全环境的第一个节点上；观察一天；部署到准生产环境的第二个节点上，再部署到生产环境的第二个节点，再部署到安全环境的第二个节点上；再观察一天；部署到准生产环境的第三个节点上，再部署到生产环境的第三个节点，再部署到安全环境的第三个节点上；第一步可以帮我们发现分布式系统内部的处理集群里，节点之间交互的代码问题。

接下来一个节点一个节点的部署，可以帮我们确认集群内部是否可以同时支持两个不同的版本，以及代码是否足够稳定。

为什么在部署节点的过程之中有两次要观察一天呢？因为这样可以让我们有充足的时间发现性能问题、数据问题或需要长时间运行才能发现的问题。到这一步时，我们就已经解决掉大部分问题了。接下来的部署步骤只是帮助我们发现一些可能的未知缺陷。

每当发现新问题时，我们都会立刻将新版本代码回滚。这样我们提供的服务就可以恢复到一个稳定的状态，我们也可以有充足的时间去修复问题，并增加相应的测试用例。

使用了这样的方法，我们的测试用例集就是客户的真实使用场景。这样效率就非常高了，我们可以每周都发布新版本，满足客户的需求。尽管我们的代码量已经非常庞大，我们仍然做到了这一点。

初创公司的生态环境是相当严峻的。小团队要找到高效的方法，打造出比大公司的大团队更好的产品。

定期发布新功能的重要性，不亚于有着良好用户体验，可以满足用户需求的稳定产品。选择做足够的测试还是选择有足够的测试覆盖率并可以定期发布？对效率的需求逼着我们在这两者之间找到了一个中间的平衡点。

在增加新测试用例时你必须特别小心，因为要消耗的时间太多了：要花时间去写、去维护和运行。那你知道什么时候该写测试吗？90-90 法则适用于这种情况：测试一个功能 90% 的内容是非常容易而直接的，再测试剩下的 10% 会花费相同的时间。所以根据客户的使用情况来处理这剩下的 10% 非常重要，不应该追求完全的覆盖率。

为了降低风险，请多花些时间对软件和基础设施进行设计，让它们可以支持在生产环境进行测试，并把对客户的影响限制到最小。

（编辑：ASP站长网）