我听说过泳道这个术语在服务器组的上下文中使用。它可以是一个机架，里面装有特定应用程序的所有部分。从数据库到负载平衡的一切。或者可能是为某个特定客户准备的。
这是行业标准术语吗？您对该术语的起源有什么看法？其他人也使用它吗？
答案1
谷歌找到了它：
泳道 AKF 使用术语“泳道”来描述故障域或故障隔离架构。故障域是边界内的一组服务，以便包含该边界内的任何故障，并且故障不会传播到外部。这种故障域的好处有两方面：
故障检测：如果采用足够精细的方法，与识别故障时间相关的可用性组件将显著减少。这是因为查找根本原因或故障组件的所有努力都与与故障域相关的产品或平台部分隔离。故障隔离：如前所述，故障不会传播或导致平台内其他服务的恶化。因此，根据方法的不同，只有部分用户或产品的部分功能受到影响。
泳道之间绝对禁止同步调用，因为故障域之间的任何同步调用，即使有适当的超时和检测机制，也很可能引发一系列连锁故障。这种情况发生的一个例子是，在您的数据库中，一个长时间运行的查询减慢了所有其他争用锁或资源的查询的速度。
AFK Partners | 定义 Pid、碎片和泳道 http://akfpartners.com/techblog/2010/10/26/defining-pods-shards-and-swim-lanes/
答案2
和 TheCleaner 一样，我也没有听说过这个术语被这样使用。不过，我还是大胆猜测一下，一组属于单个应用程序的硬件是如何被称为“泳道”的。这个“答案”当然完全是猜测，直接进入未知的蓝色世界，仅此而已。
我已经看到看板中使用泳道术语来描述任务生命周期，因为任务会流经不同的状态，例如{“计划”、“进行中”、“等待”、“暂停”、“完成”}。以下是对泳道的错误使用的简短描述我发现这是理解它们是什么的一种非常有效的方法。
随着敏捷变得越来越普遍，Devops 探索也越来越扎根（在某些地方），运营团队面临的一个挑战是如何关联和适应敏捷方法和术语。挑战在于，这些方法和术语是用来描述开发实践的，而不是 IT 运营生命周期管理或日常维护程序。和许多其他人一样，我也面临过这种挑战。
虽然我非常愿意看到敏捷方法的好处，但聪明地尽管追求敏捷，甚至鼓励采用敏捷，但事实是敏捷术语和方法并不特别适合日常维护任务。就我而言，方法转换和术语是一个持续的挑战。对于运营项目或故障排除来说，这更容易，总的来说，我发现这些运营任务更接近开发人员的工作。我发现最简单的方法是在项目期间成为开发团队的运营部分，在这种情况下，这些问题基本上自然而然地不复存在。
因此，我的猜测是，许多 Ops 人员都曾受到过 KanBan 板或 KanBan 实践要求的约束，并以某种方式得出结论：KanBan 板泳道术语（用于跟踪相对较小的任务或任务组的进度）也可以用于基础设施生命周期管理的宏任务。
如果这个猜测确实成立，我希望明确地表示，我对这种情况的发生没有任何意见。也许是这样的：
- 强制自上而下执行并破坏逻辑？
- 收养中存在误解？
- 愤世嫉俗的幽默（由于将任务转换为方法本身就很困难）
- 敏锐的洞察力（假设他们真的一针见血）？
- 随机的天灾？
我不知道我是否接近，但探索这个想法很有趣。