38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
|
# WIP 上限与 TD 登记卫生
|
||
|
|
|
||
|
|
> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
|
||
|
|
> `core/rules/ticket-lifecycle.md`（登记册与升票）。
|
||
|
|
|
||
|
|
## 背景
|
||
|
|
|
||
|
|
某组织在并行会话规模化后观察到：在制品（WIP）无上限时，并行分支数
|
||
|
|
随会话数线性增长，合并队列深度失控，单张 PR 的"可合并窗口"被拉长到
|
||
|
|
数天——期间的 rebase/重跑 CI 成本吞噬了并行带来的吞吐增益。组织最终
|
||
|
|
把 WIP 上限稳定在 40。
|
||
|
|
|
||
|
|
## WIP cap 的作用面
|
||
|
|
|
||
|
|
- **合并出口串行**：PR 按容量串行开一张、双绿并入再开下一张，
|
||
|
|
避免合并波互相踩踏。
|
||
|
|
- **会话-工单一对一**：一张工单同一时刻只有一个归属会话（claim
|
||
|
|
纪律），WIP 上限实际上是"在飞工单数"上限。
|
||
|
|
- **超限的反应是停新开、不清在飞**：清场式批量关闭被证明是反模式
|
||
|
|
（见 `examples/sprint-mode-throughput.md`）。
|
||
|
|
|
||
|
|
## TD 登记卫生（同一场治理的另一面）
|
||
|
|
|
||
|
|
- **登记行零丢失**：任何验证阶段发现的债务候选都落登记行——
|
||
|
|
不开票、不丢弃。
|
||
|
|
- **TD 编号经台账分配**：并发会话从分配台账取连续号段，手工
|
||
|
|
"max+1"被禁止——并行竞争曾产生重号。
|
||
|
|
- **未升票行 30 天未动 → 自动回收候选**：登记不是永久停车位。
|
||
|
|
- **[COLD] 标记**：连续数个周期无人认领的行可标记冷存，不占模块
|
||
|
|
配额，一次认领即复活。
|
||
|
|
|
||
|
|
## 教训
|
||
|
|
|
||
|
|
- 吞吐治理 = WIP 上限（控入口）+ 登记卫生（控台账）两者缺一不可：
|
||
|
|
只控入口，发现会丢失；只控台账，队列会堆积。
|
||
|
|
- 上限值本身不重要（40 是该组织的经验值），重要的是**有上限且
|
||
|
|
超限行为被定义**。
|