Rachel 加入了一个新团队，她的上司 Zane 强调以指标驱动的方式，专注于以最低成本最大化小部件（widget）的产量。自动化生产线涉及复杂的软件，由于测试限制，变更仅在真实生产环境中进行验证。Rachel 的初始任务是更新一个 Google Sheets 指标仪表板，该仪表板从六个数据库拉取数据，尽管用户始终更偏好 Excel。团队仅追踪输出指标，如“单位时间内生产的小部件数量”，缺乏详细数据来解释系统行为或瓶颈。例如，自动化质量控制扫描仪并未记录拒绝小部件的原因，甚至没有直接记录被拒小部件的数量。软件变更的评估基于整体输出指标，这使得验证变得困难，因为这些指标存在噪声，且受软件本身之外的外部因素影响。Rachel 尝试实施一项变更以记录被拒小部件，最初却因环境因素而非其代码导致的指标回退而受阻。由于测试运行有限且需考虑指标回退，简单的变更可能需要数周才能验证。Rachel 开始在代码中添加仪器化（instrumentation）以收集更详细的数据，希望构建一个有用的系统模型。然而，Zane 仍固守于对关键输出指标的即时改进。他驳斥了收集数据以理解指标为何如此表现的價值，声称此类诊断数据并非“关键指标”。这造成了 Rachel 对系统理解的渴望与 Zane 对顶层绩效指标的关注之间的根本冲突。Rachel 通过一种妥协策略解决了这一矛盾：确保她为改进顶层指标所做的任何变更都包含用于解释变更行为的仪器化。这一策略使她既能满足 Zane 对指标改进的要求，又能逐步提升系统的可观测性。最终，深入理解复杂系统相较于在没有全面洞察其驱动因素的情况下推动顶层指标，始终处于较低优先级。