Engineering on QSysArch - Quantum Computer System Architecture

容量和效率工程

Sun, 22 Mar 2026 00:00:00 +0000

我最近接触到了容量与效率工程的概念，这是一门旨在以最优方式设计和运行系统的学科。它是系统架构的关键支柱，在规模至关重要的领域（例如量子计算系统）尤为重要。

简而言之，产能与效率工程是一门优化生产的科学或学科。它通过平衡最大产量（产能）与资源消耗（效率）来实现这一目标。

容量与效率工程（CEE）的优势在于它是一个定义明确的领域，文献资料丰富，并有完善的工程实践体系支撑。本备忘录旨在提炼CEE中的一些关键概念。

产能和效率工程支柱链接到标题

容量与效率工程建立在三大核心支柱之上：可观测性、建模和规划。

可观测性

→

造型

→

规划

最终目标是制定一个能够通过模型有效模拟的计划。该模型应通过实证观察进行验证。通过模拟增长、识别瓶颈并进行战略性资源分配，该计划可以防止资源过载或利用不足，从而确保系统最佳运行。

需要注意的是，系统资源可以是任何事物，包括CPU、内存等IT资源，也可以是人员或设备。事实上，CEE可以应用于各个领域。例如，它可以帮助优化项目管理中的人员配置，或者降低基础设施管理中的云托管成本。

可观测性链接到标题

可观测性是对系统进行实证分析。在计算机系统中，日志经常与可观测性混淆，但它们只是其中的一部分。例如，OpenTelemetry标准涵盖了多种可观测的“信号”：日志、指标、追踪和冗余信息。对于计算机工程和工程（CEE）而言，有效的可观测性应提供：

资源使用情况：观察和跟踪资源消耗情况。观察结果应具体说明资源的使用内容、使用时间、使用者以及是否发生任何错误。
性能指标：跟踪关键性能指标（KPI），例如延迟和吞吐量。包括良率、浪费率或错误率。
瓶颈识别：找出系统中降低吞吐量的制约因素。

关键在于能够对系统进行事后分析，并且无论在高负载、维护还是空闲期间，都必须进行分析。详细了解发生了什么、何时发生以及为什么发生至关重要。如果没有这些可观察的数据，就无法确定系统故障的根本原因。

当然，要收集完整系统的全部观测数据并非易事：观测成本可能非常高昂，甚至可能具有破坏性（例如在量子计算中，测量系统会改变其状态——这种现象被称为观测者效应）。这意味着，仅仅是观测系统这一行为本身就可能改变其行为并降低其性能。解决这个问题的方法是采样（仅收集部分事件的数据，而非全部事件）。其核心思想是将采样率（数据收集频率）作为可调的系统参数，如下图所示（图片来源：OpenTelemetry）。

对于非计算系统而言，有效的可观测性能够解释项目延期的原因。可观测数据很可能是 ISO9001 标准规定的技术和非技术文档，这些文档解释了项目每个阶段所做的可追踪决策。

建模链接到标题

在可观测性建立之后，就可以开始理解系统的分析参数行为。这种行为构成了下一个支柱的基础：它可以被描述并转化为参数模型。下一步是明确在给定一组参数或条件的情况下，这样的模型需要提供什么：

性能：系统能够提供的最大吞吐量和延迟是多少？
运行成本：以分配的资源数量来衡量，运行该系统需要多少成本？该成本可能因一天中的不同时间而异。
重新配置：更新系统参数会产生哪些瞬态影响（暂时性影响）？例如，分配新服务器或 QPU 并对其进行正确配置时。

关键在于模拟系统行为并观察其在不同运行条件下的性能。由于该模型包含了资源成本，因此可以展现这些条件下的成本权衡。这些信息对于规划阶段至关重要。

这里值得一提的是_仿真_和_模拟_之间的区别。从宏观层面来说，模拟创建了一个系统的模拟版本，而仿真则基于系统的抽象模型进行操作。使用模拟，由于输入相同，因此可以将模拟性能与实际性能进行比较。我认为在CEE的语境下，模型主要指的是模拟器。

一个好的非计算系统模型可以预测向项目中添加更多资源的影响。事实上，有时添加资源反而会降低系统性能。这种违反直觉的结果被称为布鲁克斯定律。

规划链接到标题

有了模型，就可以开始规划系统运行了。利用模型模拟各种情况，找出最优方案。根据这些结果，策略性地分配资源以满足需求。一个好的计划应该包含需求预测、成本管理和故障保护措施。预测用于预测未来的使用情况、流量或需求。成本控制用于控制资源过度配置，同时确保高峰时段的容量。故障保护措施则提供缓冲，以应对意外需求。

关键在于高效可靠地运行系统，应对峰值负载而不发生故障，确保成本效益，通过预测容量实现主动重新配置，并提供足够的缓冲来应对意外事件。

该计划结合了最佳情况（需求符合预期）和最差情况（需求高于或低于预期）。这种方法实现了产能的成本效益最优配置。

微调模型链接到标题

先有鸡还是先有蛋的问题

组织复杂性：多一些架构，少一些管道

Sun, 30 Nov 2025 00:00:00 +0000

这份备忘录是从 l’Observatoire du Long Terme 转录而来，随后是一段关于建筑师在规模扩张中的作用的个人论述。

从曼哈顿城市规划中学习链接到标题

曼哈顿南部狭窄、不规则的街道——街道名称难以预测，交叉路口角度也千差万别——与纽约其他地区形成鲜明对比，纽约其他地区街道呈网格状，街道（从第一街到第220街）和大道（从第一街到第十二街）宽阔，并以直角相交。

原因在于历史背景：17世纪初纽约作为荷兰贸易站时，并没有城市规划。街道的走向取决于居民的行走路线或根据需要而建，缺乏整体规划。这使得前往纽约更加困难（尤其是对外国游客而言），公共工程的规划更加复杂，城市发展也更难组织有序。

曼哈顿南部是由水管工（他们处理的是眼前的需求）规划的，而纽约的其他地区则是由建筑师（受到长期交通需求愿景的启发，并关注简洁性和整体效率）设计的。

数字系统链接到标题

同样的道理也适用于行政系统。有些系统旨在优化用户时间，但代价是增加了架构方面的投入。另一些系统则通过堆砌繁文缛节和语无伦次的文本来减少规则制定者的工作量，就像水管工从一个漏水点跑到另一个漏水点一样。

新加坡在第一类政策中占据主导地位，其采用的是一种工程化方法，旨在以最大程度提高用户效率的方式设计和管理公共政策。每一项新规都必须证明其具有足够的效益，现有法规也会定期接受效率审查，以优化其有效性，并在不再需要时予以废除。新加坡还制定了功能性架构规则，以优化文本和流程的效率，从而提升用户体验。这些规则包括通用数据标准、广泛使用预填表格（基于标准数据）以及强制使用通用软件组件（例如，用于支付或数据收集）。

负责数字化工作的机构扮演着关键的“首席架构师”角色，并依靠各部委的“职能架构师”来实施相关标准。数字技术通常是简化或“协调流程”的关键因素：在流程数字化过程中，流程本身或其所需信息和文档的过度多样性所带来的成本才会显现出来。在数字化之前，这种复杂性由用户承担。而通过数字化，这种多样性的成本以及协调各部门间不同流程所带来的益处都会变得显而易见。

(图片来源：Agentic Design Patterns)

正常镜链接到标题

在法国，企业和用户承受着欧洲最高的行政繁琐程度之一，据法国长期观察站估计，这相当于GDP的6个百分点（约1700亿欧元）。过去的简化举措往往是一次性的，无论是通过审查（通常被新的文本所掩盖）还是重写法律条文（通常随后又被修改，增加了复杂性）。

有两种途径可以扩大这项工作的规模并使其长期有效。第一种途径是重组行政生产，引入受软件/信息技术城市化启发的架构原则和以用户为中心的方法（而非以行政为中心的方法），正如新加坡所做的那样。

第二点是评估“时间税”并设定目标——例如，减少500亿欧元。可以从有限的手段入手——例如，抽样调查前100项主要手续所花费的时间。一个名为“规范镜”（normoscope）的协作工具还可以让用户分享他们在办理手续时遇到的不足之处。鉴于法国家庭的经济状况比以往任何时候都更加拮据，我们需要帮助他们摆脱那些对生活质量没有益处的负担。

就行政复杂性而言，这意味着__多一些架构，少一些管道__。

题外话：如何组织规模化企业中的复杂性链接到标题

我常常思考，为什么有些初创公司能够发展成为成功的规模化企业，而另一些却举步维艰。这通常归结于是否让合适的人在合适的岗位上。要做到这一点，理解架构师的真正职责至关重要。

汤、厨房和菜单链接到标题

把创业公司想象成一家专营汤的餐厅。第一道汤大获成功，带动了餐厅的发展。随着餐厅规模的扩大，厨师人数增加，菜谱也随之增多，运营变得更加复杂。每增加一位新厨师和一道新菜谱，厨房的运转速度就会减慢。为了解决这个问题，创业公司的创始人决定设立一个项目管理办公室（PMO），以确保一切步入正轨。

项目管理办公室（PMO）团队很快发现，一个重要的环节出了问题：厨房运作缺乏清晰的计划。他们尝试通过给每位厨师分配具体职责、使用详细的任务单组织任务、并根据预估工作量制定总体规划来解决这个问题。但这些措施都无济于事。PMO 百思不得其解。明明所有事项都已记录在案，为什么还是行不通呢？

问题在于，这本书只讲了如何做汤，却没讲汤应该是什么。项目管理办公室（PMO）没有意识到，他们不再只是做一种汤了——他们拥有的是一种可以用来制作不同菜肴的“汤底”，具体取决于产品经理（PM）制定的菜单。PMO团队没有解决真正的问题，只是在“铺设”流程，就像没有规划就修路一样。

项目管理办公室真正需要的是一个设计完善的系统，能够让一切顺利运行，并随着时间的推移不断扩展，就像曼哈顿北部的道路一样。项目管理办公室的错误在于没有意识到他们需要一位架构师来制定蓝图，指导他们如何组织复杂的流程。

在许多快速发展的公司中，通常只有一个工程总监，他/她不仅负责架构设计，还负责确保团队拥有成长型思维。其目标是赋能团队，让他们自主提升效率，而不是强加效率。只有完成这些步骤，公司才能真正做好规模化发展的准备！

项目驱动型组织链接到标题

我最近偶然读到哈佛商业评论上的《项目驱动型组织》这篇文章。我很欣赏它围绕组织设计、领导力和价值创造这三大杠杆构建的结构化方法。但文章缺少一个关键细节：如何将这些想法转化为盈利产品的策略。

下图是对原始概念的重新诠释，我在此基础上添加了“路线图”这一关键要素，可以将其理解为将创意转化为盈利产品的“战略”。我还添加了“工程团队”，作为连接不同团队的纽带。

在这个图中，是建筑师为道路规划提供意见？还是道路规划作为输入提供给建筑师？抑或是由建筑师为项目团队提供意见？所有答案都正确，具体取决于上下文。关键在于，工程团队负责道路的建设，他们需要一个可以遵循的规划，或者说一个可以“实现”的架构。

将项目转化为利润

下图展示的是厨房的设计和布局有多么出色？还是仅仅展示了项目管理办公室（PMO）如何高效运营并将其转化为利润？

(图片来源：)

结论链接到标题

当事情变得过于复杂和失控时，想想如何用这两条简单的规则来组织复杂性：多搞架构，少搞管道！

Engineering on QSysArch - Quantum Computer System Architecture

容量和效率工程

产能和效率工程支柱 链接到标题

可观测性 链接到标题

建模 链接到标题

规划 链接到标题

微调模型 链接到标题

组织复杂性：多一些架构，少一些管道

从曼哈顿城市规划中学习 链接到标题

数字系统 链接到标题

正常镜 链接到标题

题外话：如何组织规模化企业中的复杂性 链接到标题

汤、厨房和菜单 链接到标题

项目驱动型组织 链接到标题

结论 链接到标题