我听说过在服务器组中使用的泳道这个术语。 它可以是容纳特定应用程序的所有部分的机架。 从数据库到负载平衡的一切。 或者，也许为一个特定的客户。
这是一个行业标准术语？ 任何有关该术语起源的想法？ 别人也使用它吗？
那么谷歌发现它：
游泳泳道AKF使用术语“泳道”来描述故障域或故障隔离体系结构。 失败域是边界内的一组服务，使得包含该边界内的任何失败，失败不会传播到外部。 这种失败领域的好处是双重的：
故障检测：给定一个足够精细的方法，与识别故障的时间相关的可用性组件大大减less。 这是因为所有find根本原因或失败组件的努力都与产品或与失败域相关联的平台部分隔离。 故障隔离：如前所述，故障不会传播或导致平台内其他服务的恶化。 如此，并且取决于方法，仅一部分用户或产品的function的一部分受到影响。
在泳道之间，同步调用是绝对禁止的，因为即使有适当的超时和检测机制，故障域之间的任何同步调用都很可能导致一连串的故障。 当一个长时间运行的查询减慢了所有其他查询争夺锁或资源的速度时，数据库中发生这种情况的一个示例。
AFK合作伙伴| 定义PID，碎片和泳道http://akfpartners.com/techblog/2010/10/26/defining-pods-shards-and-swim-lanes/
就像TheCleaner一样，我也没有听过这个词的用法。 不过，我会冒险猜测一个属于单个应用程序的硬件是如何被称为“游泳池”的。 这个“答案”当然是纯粹的猜测，直到未知的蓝色，没有别的。
我已经看到KanBan董事会用来描述任务生命周期的Swimlane术语，因为任务stream经不同的状态，如{“计划”，“进行中”，“等待”，“搁置”，“完成”}。 这里是一个简短的描述不正确的使用Swimlanes ，我发现它是一个相当有效的方式了解它们是什么。
随着敏捷变得越来越普遍，Devops的探索需要更坚实的基础（有些地方），运营团队面临的一个挑战是如何与敏捷方法和术语联系起来。 面临的挑战在于这些已经被用来描述开发实践，而不是像IT运营生命周期pipe理或日常维护程序那样。 像其他许多人一样，我也受到了这个挑战。
尽pipe我非常愿意在智能追求下看到敏捷方法的好处，甚至达到鼓励采用的目的，事实仍然是，敏捷术语和方法学不适合例如日常维护任务。 就我而言，方法转换和术语是一个持续的挑战。 通过运营项目或解决问题更容易，总的来说，我发现那些OPS任务更接近开发者所做的。 我觉得最容易的是当一个项目的Devs团队的一个操作部分，这些问题很大程度上和自然地不复存在。
所以我猜测是一群Ops的人受到了Kanban板或Kanban的做法的要求，并得出结论认为KanBan Board Swimlane这个术语是为了跟踪相对较小的任务或任务组的进展用于基础设施生命周期pipe理的macros任务。
如果这个猜测其实应该是真的，我希望对这个情况是怎样的一点都不要有意见。 也许是这样的：
我不知道我是否接近，但探索这个想法很有趣。