Back to Details

thinking-theory-of-constraints

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Theory of Constraints

约束理论（Theory of Constraints）

A throughput-limited system has one binding constraint. Improve only that constraint; local optimization of non-constraints wastes effort and often grows WIP.
吞吐量受限的系统存在一个绑定约束。仅针对该约束进行优化；对非约束环节进行局部优化只会浪费精力，且通常会增加在制品（WIP）数量。

When to Use

适用场景

  • Latency or throughput goal where one stage dominates time or rate.
  • Work piles up before one stage; downstream idles.
  • Adding capacity/workers elsewhere does not raise end-to-end output.
  • Need ordered plan: exploit cheaply before spending to elevate.
  • 延迟或吞吐量目标受某一环节的时间或速率主导时。
  • 某一环节前出现工作堆积，下游环节处于空闲状态时。
  • 在其他环节增加容量/人力无法提升端到端输出时。
  • 需要有序规划：在投入资源提升前先低成本充分利用现有约束环节时。

When NOT to Use

不适用场景

  • Load is spread; no stage dominates—use systems for interactions.
  • Problem is correctness/fault, not flow rate—debug the fault.
  • Bottleneck hops every run due to coupling/contention without a stable stage—systems or concurrency design, not five focusing steps.
  • Constraint already known and a cheap fix is ready—apply it without ceremony.
  • 负载分散，无主导环节——需采用交互系统相关方法。
  • 问题在于正确性/故障，而非流转速率——直接调试故障即可。
  • 由于耦合/竞争，每次运行时瓶颈都会转移，无稳定主导环节——需采用系统或并发设计方案，而非五步聚焦法。
  • 约束已明确且有现成低成本修复方案——直接实施即可，无需遵循该流程。

Procedure

实施步骤

  1. Define the flow and goal. Name the unit of work (request, job, PR, record) and the metric that matters (end-to-end rate or latency).
  2. Identify the constraint with evidence. Compare stages on utilization, queue/wait, and throughput. Constraint signals: near-100% use, longest queue, lowest stage rate, work piles here, more input does not raise system output. Prefer measured rates over opinions. If two candidates tie, pick the one whose improvement would raise system throughput first.
  3. Exploit (no major spend). Maximize constraint output: cut idle, drop nonessential work on the constraint, reduce rework/setup, protect its time, improve quality at the constraint so output is not wasted. Estimate gain before spending.
  4. Subordinate non-constraints. Pace upstream to constraint rate; do not flood WIP. Make other stages serve the constraint (readiness, clarity, immediate pull). Reject local utilization targets that grow queues before the constraint.
  5. Elevate only if still short. After exploit is maxed, invest to raise constraint capacity (people, tooling, sharding, parallel path). Choose cheapest adequate elevation.
  6. Recheck (prevent inertia). After elevation or large exploit, remeasure all stages—the constraint often moves. Return to step 2. Do not keep optimizing the old constraint.
Stop when constraint, evidence, exploit plan, subordination rules, and elevate-or-not decision are explicit—or when no single stage binds (exit to systems).
  1. 定义流转流程与目标。明确工作单元（请求、任务、PR、记录）以及关键指标（端到端速率或延迟）。
  2. 凭证据识别约束环节。对比各环节的利用率、队列/等待时间以及吞吐量。约束信号包括：利用率接近100%、队列最长、环节速率最低、工作在此堆积、增加输入无法提升系统输出。优先采用实测数据而非主观判断。若两个候选环节难分伯仲，选择优化后能率先提升系统吞吐量的那个。
  3. 充分利用（无大额投入）。最大化约束环节的输出：减少空闲时间、移除约束环节上的非必要工作、减少返工/准备时间、保障其工作时长、提升约束环节的输出质量以避免浪费。在投入资源前先预估收益。
  4. 从属调整非约束环节。上游环节的速率需与约束环节保持一致；避免在制品（WIP）堆积。让其他环节配合约束环节（做好准备、明确需求、即时响应拉取）。拒绝会导致约束环节前队列堆积的局部利用率目标。
  5. 仅在仍有缺口时提升扩容。在充分利用环节的潜力被挖掘殆尽后，再投入资源提升约束环节的容量（人力、工具、分片、并行路径）。选择成本最低且能满足需求的扩容方案。
  6. 重新检查（避免惯性）。在扩容或大幅优化后，重新测量所有环节——约束环节通常会发生转移。回到步骤2，不要继续优化原约束环节。
停止条件：当约束环节、证据、充分利用方案、从属调整规则以及是否扩容的决策都已明确时，或者当不存在单一绑定环节时（转而采用系统层面方案）。

Output

输出结果

text
system_goal: <throughput/latency objective>
flow: <stage sequence>
constraint: <stage or resource>
evidence: <utilization / queue / rate facts>
exploit: <actions, expected gain>
subordinate:
  - stage: <name>
    change: <how it serves the constraint>
elevate: <none | option + cost/gain>
next_constraint_watch: <what to remeasure after change>
text
system_goal: <throughput/latency objective>
flow: <stage sequence>
constraint: <stage or resource>
evidence: <utilization / queue / rate facts>
exploit: <actions, expected gain>
subordinate:
  - stage: <name>
    change: <how it serves the constraint>
elevate: <none | option + cost/gain>
next_constraint_watch: <what to remeasure after change>

Verification

验证方法

  • Falsify: If raising the named stage cannot increase system throughput (another stage already caps), identification is wrong. If non-constraint optimizations change end-to-end rate, re-identify.
  • Stop: Do not elevate before exploit is exhausted. Do not optimize multiple stages “just in case.”
  • Over-application guard: One constraint at a time. Idle capacity upstream is not a problem to fill. Do not use TOC language for pure multi-loop emergence without a binding stage.
  • 证伪： 如果提升指定环节无法增加系统吞吐量（另一环节已成为瓶颈），说明约束环节识别错误。如果优化非约束环节能改变端到端速率，需重新识别约束环节。
  • 停止准则： 在充分利用环节潜力耗尽前不要进行扩容。不要“以防万一”同时优化多个环节。
  • 过度应用防范： 一次只处理一个约束环节。上游的空闲容量无需刻意填满。若不存在绑定环节，仅为多循环涌现问题，请勿使用约束理论（TOC）相关方法。