遗憾的是，答案取决于你特定的需求、发展速度、不可用性以及造成系统不可用的原因、客户对可用性的期望值、签署的可用性承诺以及各种因素的组合，它们产生的组合数量巨大，以至于我们不能向你描述出你的环境究竟需要什么。

　　无论你做什么，都要确保把最能赚钱的功能正确地与故障和其他系统的需求约束隔离开来。如果你运营的是一个电子商务站点，那么这可能是点击“购买”按钮触发的购买流程，也可能是处理信用卡时的结账流程。如果你运营的是一个提供内容的站点，通过专有的广告发布系统赚钱，那么就要确保广告发布系统的功能与系统其他一切功能分离开来。如果你的站点是靠日常的注册费赚钱的，那么就要确保从注册到开账单的流程都被正确地故障隔离了。

　　你也许有一些次级流程也 与站点赚钱的功能紧密相关，那么理所当然应该也考虑为它们施加泳道。例如，在一个电子商务站点中，可能需要把搜索和浏览功能都放入泳道。在一个提供内容的站点中，可能需要把访问流量最大的区域放在它们自己的一个或多个泳道中，以帮助需求和产能推测。社交网络站点应该为最常被访问的个人信息页面全部或部分创建泳道。

　　如果你在不断地执行季度故障回顾会议(如第8章所述)，你发现你站点中的某些组件在反复地引发故障，那么在将来的余量项目中，绝对应该考虑这些组件，并且应该把这些区域隔离起来。季度故障回顾会议的目的是从我们过去的错误中吸取教训。如果由需求造成的可用性问题反复发生，我们就应该把这些区域隔离起来，以防它们影响产品或平台的其他部分。

　　在多租户的SaaS系统中，这种方法尤其有用，这种系统通常需要沿着Z轴扩展，需要最大可扩展性的站点和平台通常都必须依靠沿Z轴的分段进行扩展，而最常用的是按照客户进行划分。虽然这种划分通常首先是在架构的存储或数据库层实现的，但是接下来，我们应该为从请求到数据存储或数据库的所有组件都创建泳道。

　　你可以把系统设计为在一一条泳道中运营一个或多个“租户”。 如果你的平台适合这样做，那就充 通常，多租户意味着你试图通过共享资源而提高成本效率。在许多情况下，这种方法意味着分利用这一点。 如果你的某个租户非常忙，就给它单独分配一个泳道。而如果你的大多数租户对你的平台的使用率都很低，那么可以把它们分配到一个泳道中。原理大致如此。