系统工程给我的三个想法

今年我开始念工程管理硕士，第一门课是系统工程方向的 Systems Validation & Testing（系统验证与测试）。上课之前我以为拿到的会是一套词汇。在最初的几周里，那套词汇确实来了，以 V 模型、验证矩阵和大量图示的形式。但有三个想法跟着我回到了工位，并且改变了我写集成规格的方式，而它们都与画图无关。

我想把这三个想法写下来，因为每一个都纠正了一项我带了多年却没有察觉的习惯。

想法一：没有数字附在上面，它就不是一条需求

在不止一份规格书里，我写过「同步应当接近实时」这句话，而当时我认为自己描述的是一条需求。

用系统工程的说法，那句话是一个目标，只有在一个可度量的边界被附加上去之后，它才成为一条可设计到的判据。这个区分听起来像在抠字眼，直到工程师注意到它在下游的代价。在 30 秒和在 15 分钟这两种口径下，「接近实时」描述的是两套不同的系统：前者订阅变更流，后者按计划轮询。这两种设计在成本、失效模式，以及凌晨三点谁被叫醒这三件事上都不相同。

因此我改掉的是一个小习惯，而在今年的两次请求里它已经把自己赚了回来。当一个集成请求不带数字送过来时，我不再去估算它。我把一个问题送回去，也就是「还能接受的最长延迟是多少」，然后我等。答案会在一天之内回来，而在其中大约一半的情况里，这个容差比我原本会假设的更宽松，这意味着更便宜的那套设计从一开始就是可选的。

想法二：串行依赖是相乘的，而合同决定了天花板

关于想法二，我得承认一个我算错了很多年的算术。

设想一条由 4 个服务串起来的链路，每个服务承诺 99.975% 的可用性。四个数相乘约等于 99.9%，而这正是所有人都想写到幻灯片上的那个数字。这个算术我以前做过，做的时候还觉得自己挺称职，但我一次也没有去看过那 4 个数字各自是从哪里来的。

其中一个是外部的合同依赖，而供应商自己的协议保证的是 99.9%。因此无论我在它周围建什么，这条链路都无法超过 99.9%，因为那一个环节已经独自吃掉了全部预算。重试逻辑、缓存和冗余，任何一项都挪不动一个由合同钉死的数字。

对我而言，实际的改变是操作顺序。我现在会先去读链路里最弱的那份供应商合同，然后才去看架构。如果业务需要 99.99% 而供应商卖给我们的是 99.9%，那这是一个穿着工程外衣的采购问题，它应该回到那些能够重新谈判的人手里。

想法三：先分配，再测量

在这三个想法里，这一个是我至今仍然觉得最难落实的。

当有人问一条管道有多快时，多数工程师的本能是去测它：给每一跳打点，把延迟加起来，然后报出总和。这感觉上很严谨，但它的方向是反的。你得到的东西，是对「你碰巧建成了什么」的一份描述，而随后会有一股很强的拉力，把那个数字当成目标。

分配的方向与此相反。你取业务真正需要的顶层数字，在测量任何东西之前先把它拆成每一段的预算，然后用测量去找出哪一段超了预算。一个 10 秒的端到端目标，可以分配为抽取 2 秒、转换 3 秒、加载 4 秒，外加 1 秒余量。当转换那一段测出来是 7 秒时，你找到的不只是一个慢的环节，而是一个比某个人同意过的数字超出 4 秒的环节。

在调了四年查询之后，我一直做的是前一种版本，并且把它称作分析。后一种版本并没有难多少，而它会把一场性能讨论转换成一场设计讨论，因为一个达不到自己分配额的组件，告诉你的是架构不对，而不是 SQL 不对。

我认为这个学位实际上是用来做什么的

这三个想法没有一个是复杂的。一个工程师可以在一个下午之内把它们全部读完，而我猜相当一部分人是在经历了足够多的故障之后自己想到的。

这门课给我的是一个慢下来的理由，以及把我已有习惯背后的推理写出来的机会。我认为这才是真正的价值所在，而不是那张文凭。过去几年里，我的技术学习大多发生在晚上十一点、截止日期面前，目标是让东西跑起来，理解则要更晚才到，甚至根本不到。一门结构化的课程把这个顺序倒了过来，而这种颠倒是以一种有用的方式让人不适。

我第一门课还没上完，所以请把上面这些当作初步印象而不是结论。等我上完第四门再问我一次。