<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Engineering on QSysArch - Quantum Computer System Architecture</title><link>https://qsysarch.com/zh-hk/categories/engineering/</link><description>Recent content in Engineering on QSysArch - Quantum Computer System Architecture</description><generator>Hugo</generator><language>zh-hk</language><lastBuildDate>Sun, 22 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://qsysarch.com/zh-hk/categories/engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>容量和效率工程</title><link>https://qsysarch.com/zh-hk/posts/capacity-and-efficiency-engineering/</link><pubDate>Sun, 22 Mar 2026 00:00:00 +0000</pubDate><guid>https://qsysarch.com/zh-hk/posts/capacity-and-efficiency-engineering/</guid><description>&lt;p&gt;我最近接觸到了容量與效率工程的概念，這是一門旨在以最優方式設計和運行系統的學科。它是系統架構的關鍵支柱，在規模至關重要的領域（例如量子運算系統）尤其重要。 &#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/efficiency.webp#right" alt="容量與效率工程" style="width: 100%; max-width: 150px;"/&gt;&lt;/p&gt;&#10;&lt;p&gt;簡言之，產能與效率工程是一門優化生產的科學或學科。它透過平衡最大產量（產能）與資源消耗（效率）來實現這一目標。&lt;/p&gt;&#10;&lt;p&gt;容量與效率工程（CEE）的優點在於它是一個定義明確的領域，文獻資料豐富，並有完善的工程實務體系支撐。本備忘錄旨在提煉CEE中使用的一些關鍵概念。&lt;/p&gt;&#10;&lt;h1 id="產能與效率工程支柱"&gt;&#10; 產能與效率工程支柱&#10; &lt;a class="heading-link" href="#%e7%94%a2%e8%83%bd%e8%88%87%e6%95%88%e7%8e%87%e5%b7%a5%e7%a8%8b%e6%94%af%e6%9f%b1"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h1&gt;&#10;&lt;p&gt;容量與效率工程建立在三大核心支柱之上：可觀測性、建模和規劃。&lt;/p&gt;&#10;&lt;center&gt;&lt;div style='display:inline-block'&gt;&lt;img src='https://qsysarch.com/images/capacity-and-efficiency-engineering/microscope.webp' style='width:120px;'&gt;&lt;br&gt;可觀測性&lt;/div&gt;→ &lt;div style='display:inline-block'&gt;&lt;img src='https://qsysarch.com/images/capacity-and-efficiency-engineering/modelling.webp' style='width:120px;'&gt;&lt;br&gt;造型&lt;/div&gt;→ &lt;div style='display:inline-block'&gt;&lt;img src='https://qsysarch.com/images/capacity-and-efficiency-engineering/planning.webp' style='width:120px;'&gt;&lt;br&gt;規劃&lt;/div&gt;&lt;/center&gt;&#10;&lt;p&gt;最終目標是製定一個能夠透過模型有效模擬的計劃。該模型應透過實證觀察進行驗證。透過模擬成長、識別瓶頸並進行策略性資源分配，該計劃可以防止資源過載或利用不足，從而確保系統最佳運作。&lt;/p&gt;&#10;&lt;p&gt;&#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/capacity-and-efficiency-engineering-pillars.webp" alt="容量和效率工程" /&gt;&lt;/p&gt;&#10;&lt;p&gt;要注意的是，系統資源可以是任何事物，包括CPU、記憶體等IT資源，也可以是人員或設備。事實上，CEE可以應用於各個領域。例如，它可以幫助優化專案管理中的人員配置，或降低基礎架構管理中的雲端託管成本。&lt;/p&gt;&#10;&lt;h2 id="可觀測性-容量與效率工程"&gt;&#10; 可觀測性 &#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/microscope.webp#right" alt="容量與效率工程" style="width: 100%; max-width: 150px;"/&gt;&#10; &lt;a class="heading-link" href="#%e5%8f%af%e8%a7%80%e6%b8%ac%e6%80%a7-%e5%ae%b9%e9%87%8f%e8%88%87%e6%95%88%e7%8e%87%e5%b7%a5%e7%a8%8b"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;可觀測性是對系統進行實證分析。在電腦系統中，日誌經常與可觀測性混淆，但它們只是其中的一部分。例如，&lt;a href="https://opentelemetry.io/" class="external-link" target="_blank" rel="noopener"&gt;OpenTelemetry&lt;/a&gt;標準涵蓋了多種可觀測的「訊號」：日誌、指標、追蹤和冗餘資訊。對於電腦工程和工程（CEE）而言，有效的可觀測性應提供：&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;&#10;&lt;p&gt;資源使用：觀察並追蹤資源消耗。觀察結果應具體說明資源的使用內容、使用時間、使用者以及是否發生任何錯誤。&lt;/p&gt;&#10;&lt;/li&gt;&#10;&lt;li&gt;&#10;&lt;p&gt;效能指標：追蹤關鍵效能指標（KPI），例如延遲和吞吐量。包括良率、浪費率或錯誤率。&lt;/p&gt;&#10;&lt;/li&gt;&#10;&lt;li&gt;&#10;&lt;p&gt;瓶頸辨識：找出系統中降低吞吐量的限制因素。&lt;/p&gt;&#10;&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;關鍵在於能夠對系統進行事後分析，無論在高負載、維護或空閒期間，都必須進行分析。詳細了解發生了什麼、何時發生以及為什麼發生至關重要。如果沒有這些可觀察的數據，就無法確定係統故障的根本原因。&lt;/p&gt;&#10;&lt;p&gt;當然，要收集完整系統的全部觀測資料並非易事：觀測成本可能非常高昂，甚至可能具有破壞性（例如在量子運算中，測量系統會改變其狀態－這種現象稱為觀測者效應）。這意味著，僅僅是觀測系統這一行為本身就可能改變其行為並降低其性能。解決這個問題的方法是採樣（僅收集部分事件的數據，而非全部事件）。其核心思想是將取樣率（資料收集頻率）作為可調的系統參數，如下圖所示（圖片來源：&lt;a href="https://opentelemetry.io/docs/concepts/sampling/" class="external-link" target="_blank" rel="noopener"&gt;OpenTelemetry&lt;/a&gt;）。&lt;/p&gt;&#10;&lt;p&gt;&#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/observation-sampling.webp" alt="觀測抽樣" /&gt;&lt;/p&gt;&#10;&lt;p&gt;對於非計算系統而言，有效的可觀測性能夠解釋專案延期的原因。可觀測資料很可能是 ISO9001 標準規定的技術和非技術文檔，這些文檔解釋了專案每個階段所做的可追蹤決策。&lt;/p&gt;&#10;&lt;h2 id="建模-容量與效率工程"&gt;&#10; 建模 &#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/modelling.webp#right" alt="容量與效率工程" style="width: 100%; max-width: 150px;"/&gt;&#10; &lt;a class="heading-link" href="#%e5%bb%ba%e6%a8%a1-%e5%ae%b9%e9%87%8f%e8%88%87%e6%95%88%e7%8e%87%e5%b7%a5%e7%a8%8b"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;在可觀測性建立之後，就可以開始理解系統的分析參數行為。這種行為構成了下一個支柱的基礎：它可以被描述並轉換為參數模型。下一步是明確在給定一組參數或條件的情況下，這樣的模型需要提供什麼：&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;&#10;&lt;p&gt;效能：系統能夠提供的最大吞吐量和延遲是多少？&lt;/p&gt;&#10;&lt;/li&gt;&#10;&lt;li&gt;&#10;&lt;p&gt;運作成本：以分配的資源數量來衡量，運作該系統需要多少成本？該成本可能因一天中的不同時間而異。&lt;/p&gt;&#10;&lt;/li&gt;&#10;&lt;li&gt;&#10;&lt;p&gt;重新配置：更新系統參數會產生哪些瞬態影響（暫時性影響）？例如，當分配新伺服器或 QPU 並對其進行正確配置時。&lt;/p&gt;&#10;&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;關鍵在於模擬系統行為並觀察其在不同運行條件下的性能。由於模型包含了資源成本，因此可以展現這些條件下的成本權衡。這些資訊對於規劃階段至關重要。&lt;/p&gt;&#10;&lt;p&gt;這裡值得一提的是_模擬_和_模擬_的差別。從宏觀層面來說，模擬創建了一個系統的模擬版本，而模擬則是基於系統的抽像模型進行操作。使用模擬，由於輸入相同，因此可以將模擬性能與實際性能進行比較。我認為在CEE的脈絡下，模型主要指的是模擬器。&lt;/p&gt;&#10;&lt;p&gt;&#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/simulation-vs-emulation.webp" alt="模擬 vs 模擬" /&gt;&lt;/p&gt;&#10;&lt;p&gt;一個好的非計算系統模型可以預測在專案中添加更多資源的影響。事實上，有時添加資源反而會降低系統效能。這種違反直覺的結果稱為布魯克斯定律。&lt;/p&gt;&#10;&lt;h2 id="規劃-容量與效率工程"&gt;&#10; 規劃 &#10;&lt;img class="glightbox" src="https://qsysarch.com/images/capacity-and-efficiency-engineering/planning.webp#right" alt="容量與效率工程" style="width: 100%; max-width: 150px;"/&gt;&#10; &lt;a class="heading-link" href="#%e8%a6%8f%e5%8a%83-%e5%ae%b9%e9%87%8f%e8%88%87%e6%95%88%e7%8e%87%e5%b7%a5%e7%a8%8b"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;有了模型，就可以開始規劃系統運作了。利用模型模擬各種情況，找出最優方案。根據這些結果，策略性地分配資源以滿足需求。一個好的計畫應該包含需求預測、成本管理和故障保護措施。預測用於預測未來的使用情況、流量或需求。成本控制用於控制資源過度配置，同時確保尖峰時段的容量。故障保護措施則提供緩衝，以應對意外需求。&lt;/p&gt;</description></item><item><title>組織複雜度：多一些架構，少一些管道</title><link>https://qsysarch.com/zh-hk/posts/organizing-complexity/</link><pubDate>Sun, 30 Nov 2025 00:00:00 +0000</pubDate><guid>https://qsysarch.com/zh-hk/posts/organizing-complexity/</guid><description>&lt;p&gt;這份備忘錄是從 l&amp;rsquo;&lt;a href="https://longterme.org/2025/11/gagner-50-milliards-en-urbanisant-la-complexite-administrative.html" class="external-link" target="_blank" rel="noopener"&gt;Observatoire du Long Terme&lt;/a&gt; 轉錄而來，隨後是一段關於建築師在規模擴張中的作用的個人論述。&lt;/p&gt;&#10;&lt;h1 id="從曼哈頓城市規劃中學習"&gt;&#10; 從曼哈頓城市規劃中學習&#10; &lt;a class="heading-link" href="#%e5%be%9e%e6%9b%bc%e5%93%88%e9%a0%93%e5%9f%8e%e5%b8%82%e8%a6%8f%e5%8a%83%e4%b8%ad%e5%ad%b8%e7%bf%92"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h1&gt;&#10;&lt;p&gt;曼哈頓南部狹窄、不規則的街道——街道名稱難以預測，交叉路口角度也千差萬別——與紐約其他地區形成鮮明對比，紐約其他地區街道呈網格狀，街道（從第一街到第220街）和大道（從第一街到第十二街）寬闊，並以直角相交。&lt;/p&gt;&#10;&lt;p&gt;原因在於歷史背景：17世紀初紐約作為荷蘭貿易站時，並沒有城市規劃。街道的走向取決於居民的行走路線或根據需求而建，缺乏整體規劃。這使得前往紐約更加困難（尤其是對外國遊客而言），公共工程的規劃更加複雜，城市發展也更難組織有序。&lt;/p&gt;&#10;&lt;p&gt;曼哈頓南部是由水管工（他們處理的是眼前的需求）規劃的，而紐約的其他地區則是由建築師（受到長期交通需求願景的啟發，並關注簡潔性和整體效率）設計的。&lt;/p&gt;&#10;&lt;p&gt;&#10;&lt;img class="glightbox" src="https://qsysarch.com/images/organizing-complexity/manhatan-map.webp" alt="" /&gt;&lt;/p&gt;&#10;&lt;h1 id="數位系統"&gt;&#10; 數位系統&#10; &lt;a class="heading-link" href="#%e6%95%b8%e4%bd%8d%e7%b3%bb%e7%b5%b1"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h1&gt;&#10;&lt;p&gt;同樣的道理也適用於行政系統。有些系統旨在優化用戶時間，但代價是增加了架構方面的投入。另一些系統則透過堆疊繁文縟節和語無倫次的文字來減少規則制定者的工作量，就像水管工從一個漏水點跑到另一個漏水點一樣。&lt;/p&gt;&#10;&lt;p&gt;新加坡在第一類政策中佔據主導地位，其採用的是一種工程化方法，旨在以最大程度提高使用者效率的方式設計和管理公共政策。每項新規都必須證明其具有足夠的效益，現有法規也會定期接受效率審查，以優化其有效性，並在不再需要時予以廢除。新加坡也制定了功能性架構規則，以優化文字和流程的效率，進而提升使用者體驗。這些規則包括通用資料標準、廣泛使用預填表格（基於標準資料）以及強制使用通用軟體元件（例如，用於支付或資料收集）。&lt;/p&gt;&#10;&lt;p&gt;負責數位化工作的機構扮演關鍵的「首席架構師」角色，並依賴各部會的「職能架構師」來實施相關標準。數位科技通常是簡化或「協調流程」的關鍵因素：在流程數位化過程中，流程本身或其所需資訊和文件的過度多樣性所帶來的成本才會顯現出來。在數位化之前，這種複雜性由使用者承擔。而透過數位化，這種多樣性的成本以及協調各部門間不同流程所帶來的益處都會變得顯而易見。&lt;/p&gt;&#10;&lt;p&gt;&#10;&lt;img class="glightbox" src="https://qsysarch.com/images/organizing-complexity/ai-modes.webp" alt="Agentic Design Patterns" /&gt; (圖片來源：&lt;a href="https://link.springer.com/book/10.1007/978-3-032-01402-3" class="external-link" target="_blank" rel="noopener"&gt;Agentic Design Patterns&lt;/a&gt;)&lt;/p&gt;&#10;&lt;h1 id="正常鏡"&gt;&#10; 正常鏡&#10; &lt;a class="heading-link" href="#%e6%ad%a3%e5%b8%b8%e9%8f%a1"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h1&gt;&#10;&lt;p&gt;在法國，企業和用戶承受著歐洲最高的行政繁瑣程度之一，根據法國長期觀察站估計，這相當於GDP的6個百分點（約1700億歐元）。過去的簡化措施往往是一次性的，無論是透過審查（通常被新的文本所掩蓋）還是重寫法律條文（通常隨後又被修改，增加了複雜性）。&lt;/p&gt;&#10;&lt;p&gt;有兩種途徑可以擴大這項工作的規模並使其長期有效。第一種途徑是重組行政生產，引入受軟體/資訊技術城市化啟發的架構原則和以使用者為中心的方法（而非以行政為中心的方法），正如新加坡所做的那樣。&lt;/p&gt;&#10;&lt;p&gt;第二點是評估「時間稅」並設定目標—例如，減少500億歐元。可以從有限的手段入手－例如，抽樣調查前100項主要手續所花費的時間。一個名為「規範鏡」（normoscope）的協作工具還可以讓使用者分享他們在辦理手續時遇到的不足之處。鑑於法國家庭的經濟狀況比以往任何時候都更加拮据，我們需要幫助他們擺脫那些對生活品質沒有好處的負擔。&lt;/p&gt;&#10;&lt;p&gt;就行政複雜性而言，這意味著__多一些架構，少一些管道__。&lt;/p&gt;&#10;&lt;p&gt;&#10;&lt;img class="glightbox" src="https://qsysarch.com/images/organizing-complexity/normoscope.webp" alt="代理設計模式" /&gt;&lt;/p&gt;&#10;&lt;h1 id="題外話如何組織規模化企業中的複雜性"&gt;&#10; 題外話：如何組織規模化企業中的複雜性&#10; &lt;a class="heading-link" href="#%e9%a1%8c%e5%a4%96%e8%a9%b1%e5%a6%82%e4%bd%95%e7%b5%84%e7%b9%94%e8%a6%8f%e6%a8%a1%e5%8c%96%e4%bc%81%e6%a5%ad%e4%b8%ad%e7%9a%84%e8%a4%87%e9%9b%9c%e6%80%a7"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h1&gt;&#10;&lt;p&gt;我常常思考，為什麼有些新創公司能夠發展成為成功的規模化企業，而有些則舉步維艱。這通常歸結於是否讓合適的人在合適的職位上。要做到這一點，理解架構師的真正職責至關重要。&lt;/p&gt;&#10;&lt;h2 id="湯廚房和菜單"&gt;&#10; 湯、廚房和菜單&#10; &lt;a class="heading-link" href="#%e6%b9%af%e5%bb%9a%e6%88%bf%e5%92%8c%e8%8f%9c%e5%96%ae"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;把新創公司想像成專營湯的餐廳。第一道湯大獲成功，帶動了餐廳的發展。隨著餐廳規模的擴大，廚師人數增加，食譜也隨之增多，營運變得更加複雜。每增加一位新廚師和一道新食譜，廚房的運作速度就會減慢。為了解決這個問題，新創公司的創辦人決定設立一個專案管理辦公室（PMO），以確保一切步入正軌。&lt;/p&gt;</description></item></channel></rss>