控制与复杂性：系统设计中的张力

# 控制与复杂性：系统设计中的张力 来源：https://ferd.ca/control-and-complexity-tension-in-systems-design.html 在软件开发领域广泛采用大语言模型（LLMs）以来，无数组织迅速调整了自身实践与结构。随着编写新代码的经济模式受到冲击，旧方法正被质疑、取代并重新利用。由于人类与LLMs并非可互换，其中的动态机制也截然不同。系统就是系统，因此无论外界如何变化，总有一些已知模式可为我们提供指引与警示。 若不退后一步审视所处系统的底层设计思维，你可能会采取自相矛盾的措施和政策。因此，本文将通过对比两种方法体系，探讨我们如何组织系统。 第一种方法基于解析分解，旨在保持对系统的控制；第二种则基于复杂系统理论视角——这类系统抗拒解析，更侧重于探究互动机制以激发有益的涌现行为。 对比这两种方法，对于厘清系统设计的假设与关键要素始终具有现实意义，尤其在当下提出新型变革方案时尤为重要。 ### 方法体系 #### 解析分解与控制 经典科学、工程学及众多管理形式的核心思想在于：整体可通过局部被理解。只要将复杂事物分解到足够细致的程度，彻底掌握每个组件，便能理解整体运作方式。这种解析分解法（有时被称为“笛卡尔-牛顿式方法”）在现代生活的无数领域始终可靠且值得信赖。 这种分解、分析与理解的能力通常延伸到对因果关系的把握：每个作用都有反作用，每个事件都有物质性成因，这些均可被客观追溯、评估或检验。由此可推导：若我们对某物体理解足够深入，就能预测其在外部作用下的行为。 这为构建具有可预测性与可靠性的机器与流程奠定了基础。你可以设定高层目标并整合众多独立部件，通过分解问题、组装经过充分测试且符合容差的组件，最终形成可运行的解决方案。其推论是：若机器各部件均能正常发挥作用，则整体也应运转良好。 这要求驯服混乱无序的世界，通过控制参数将变异性约束在一定范围内。设计足够的容差与冗余，系统就能正常工作。若出现问题，我们可深入拆解、查明故障、修复问题并从中改进。 这种方法无处不在：从信号处理与电信领域（通过冗余机制检测并纠正有损信息传输），到工业质量控制领域（使用统计流程界定生产可接受边界(https://surfingcomplexity.blog/2024/11/23/ttr-the-out-of-control-metric/)）。 在人类层面同样可见：人因工程学中构建了诸如工作记忆（典型操作员可同时处理的信息量）或理想观察者（理论上的最优监测频率，用于定义“疏忽”标准）等概念，旨在确保人类参与的系统能将行为控制在期望参数内。 在组织层级亦有体现：官僚流程与等级制度旨在实现自上而下的协调，使整体协同运作。纪律机制与可辨识性原则共同作用，使组织演进处于可控状态。在更宏观尺度上，组织常试图控制其环境、市场或立法背景。 本质上，通过界定流程内部可接受的混乱程度，我们能在外部建立更清晰的接口供他人交互。这种抽象化为将复杂组件整合为可管理单元提供了简洁有效的途径。 软件恰好体现了这种思维模式的理想状态：系统可用确保确定性（这种确定性来之不易）的编程语言编写。执行过程理想化地始终如一，无需考虑物理损耗，昨日有效方案明日依然普适。远离执行层制定的政策决策，可确定性地在各层级贯彻实施。 这意味着系统可自下而上由组件构建，同时与自上而下的意图对齐，限制源于制造或人类行为的变异性。理想系统应具备高度可预测性、可控性、竞争力与反应能力。 #### 复杂性与涌现 问题在于，从定义上看，复杂系统抗拒解析分解。 关于复杂系统存在诸多竞争性描述，有些侧重行为模式，有些关注结构特征。但核心可归结为：“事物间高度互联且状态繁多，导致它们变得难以表征、无法预测或难以控制。” 其他关键特征包括：这类系统具有动态性，深受自身历史影响，同时也是开放系统——它们持续变化并以超越清晰边界的方式互动。这便产生了张力：众多参与者持有不同目标、视角、表征方式和自主权限。当你分析完成时，系统已面目全非。甚至观察系统本身就会对其产生重大影响。 换言之，若你对系统行为感到意外，待查明真相时，系统已发生改变，你的政策调整要么滞后，要么引发更多反直觉的意外。复杂系统更多是被影响而非被控制。 这种动态性催生了鼓励动态调整的策略。由于无法使其可预测，干预措施往往规模小且呈迭代性。或者，若无法简化你试图控制的元素或交互，可以增强控制行为的多样性，使持续调整更有效。这通常意味着“设置一个控制器（人类或其他形式），使其内部复杂度足以抵消被控对象的复杂性(https://pespmc1.vub.ac.be/REQVAR.html)。”用控制论术语来说，这是尝试建立更具适应性的动态控制机制。 平衡并非通过维持静态实现，而是通过保持运动状态达成。 理想系统应具备自我感知与灵活性，能在持续增长的挑战中不断适应并维持自身。但这种理想状态能否实现尚存疑问。 ### 方法体系的融合（或失效） 系统通常从对问题及其潜在解决方案的约束性定义中演进而来，这种定义需兼具可行性与有效性。随着运营范围和规模扩大，进一步试图引导系统的干预措施收效递减，且日益产生非预期效应。这正是复杂系统效应在事物纠缠中的体现。 我最常观察到的应对机制是加倍投入：进行更多分析、更多分解，并投入更多资源构建覆盖更广用例的灵活自动化系统。这反过来改变了成功与失败的性质——事故发生频率可能降低，但单次事故规模增大。此类融合通常通过替换故障部件（若可能）或纯粹偶然实现，鲜少形成有序进程。 更罕见的机制则试图探索：在可承受范围内放弃多少分析与控制中心式方法，识别哪些要素完全不可改变，然后从此处向外扩展复杂性认知机制。这种立场令人不安，因为它要求你放弃“实际掌控中”的认知——这对企业而言是极不愿公开的窘境。 关于大型事故是否真能避免，长期存在争论。例如让-克里斯托夫·勒科泽提出以下分类( http://dx.doi.org/10.1016/j.ssci.2014.03.015)： 图示展示事故不可预测性的三种理论解释：技术失控（埃吕尔/佩罗）、易错的人类建构（库恩/特纳/维克/沃恩）与自组织涌现系统（阿什比/拉斯穆森/斯努克/霍尔纳格尔）。 1. **确定性脉络**：技术系统自身特性（如紧耦合与复杂性）终将突破事故预防努力。 2. **认知分支**：聚焦“预见失败”概念——权力结构忽视或拒绝接受事故孕育期的微弱信号，世界观无法适应新挑战，导致事故发生。 3. **自组织脉络**：将系统视为适应性实体，将成败视为系统通过现有资源探索问题与解决方案空间的自组织涌现结果。 这些不同观点并非完全互斥，不同流派的学者常相互借鉴。但每种视角都有其焦点：控制结构、系统历史沿革、权力结构动态、系统的适应性变化本质、参与者的有限视角、文化概念等。 尽管许多争论参与者认为事故不可预测或难以避免，他们仍致力于寻找能降低事故概率的解释。通过审视已知方法的局限性，拓展认知边界，引入能揭示新洞见的新视角。 跨学科领域已有大量文献，可帮助我们更好地理解什么方法无效（以及何时无效），以及何种方案具有情境效用。本文提供的“分析解构求控制”与“复杂性促涌现”的对立框架虽显粗略且缺乏细致层次，但有望成为思考系统变革的有效工具。 这里我们进行的是简化处理，而明确简化方向至关重要。正如乔治·博克斯（1976年）所言：“由于所有模型都是错误的，我们必须警惕那些具有重要性的错误。” ### 实践中的方法对比 以下示例以略带夸张的方式，展现软件相关话题在分析解构（侧重控制）与复杂性（刻意限定于影响）两种视角下的典型观点： | 话题 | 分析解构/控制 | 复杂性/涌现 | | :--- | :--- | :--- | | **培训与教育** | 构建明确的课程体系、为教师制定最佳实践规范，并通过测试机制确保学生产出可预测且统一 | 创造促进探索、实验与信息交流的环境；提供指导与支持 | | **安全性** | 预防导致失败的不良行为。危害需被控制或通过设计消除，偏离流程或最佳实践被视为风险 | 激发导向成功的积极行为。探究人们如何弥合流程差距、规避障碍并从问题中恢复 | | **正确性** | 软件按规格或API声明运行。测试通过、功能完整，且在已知边界内运作 | 用户或客户能成功完成任务；目标可根据其需求调整 | | **可靠性** | 运行时间在可接受范围内，可通过SLA、SLO等验证。负载测试与充分验证可防止宕机 | 若客户不满则九个九毫无意义。软件在投产前无法确知是否有效，需为恢复与应对意外做准备 | | **事件应对** | 运维手册定义最佳实践。制定协议流程以高效调查与分类问题。构建清晰信息与快速诊断能力。调查故障根源以防重演 | 意外可能需要临场应变。未知情况需建立应对能力。调查必须观察常规工作，首先理解系统如何运作 | | **功能开发** | 了解用户需求及当前产品的优劣势，从而确定开发内容与方式 | 通过实地测试潜在功能并迭代，是发现有效功能的最佳途径 | | **标准与规范** | 基于可验证流程与结果明确编写，确保执行具有可行性、可扩展性与清晰度 | 以目标导向方式编写，支持和指导执行工作的人员，使其可根据实际情况调整规则 | 对于每类话题，所采取的态度会推动人们选择截然不同的方法与活动，其中部分方法可能永无交集——控制成本与错误的驱动力可能阻碍实验的有效性或意愿，而关于复杂系统运作方式的认知可能与各种常规问责措施相悖。 之所以说此表格具有夸张性，是因为现实中界限并非如此清晰或表面。例如，控制中心化的层级结构既能通过目标对齐管理层并授权下放以应对系统复杂性，也可能基于权力者的信任关系强调控制。集中控制在分析解构层面最为有效，但也存在非控制中心化方法从中受益的情况。 实际上，许多活动可用于两种方法体系，服务于不同人群，甚至同时服务于同一人： | 活动 | 分析解构/控制 | 复杂性/涌现 | | :--- | :--- | :--- | | **代码评审** | 发现缺陷与错误；追踪分配责任；确保质量 | 增强团队内外意识并提供反馈空间 | | **SLO采纳** | 确保所有团队妥善管理可靠性的组织工具 | 通过团队讨论定义可接受可靠性水平的价值优先排序工具 | | **重构** | 偿还技术债务、降低复杂性、提升可维护性与灵活性、标准化使用模式 | 抵抗熵增，基于新信息或变化需求使代码库适应新环境 | | **混沌工程** | 验证系统能妥善容忍或恢复预期故障场景 | 以实验驱动的实践，参与者形成故障场景下的系统行为理论并尝试验证 | | **平台使用** | 共享平台可鼓励良好架构模式、避免不良模式，同时为构建于其上的团队抽象复杂性 | 平台通过商品化共享元素使系统受益，同时支持执行工作的人员根据现实调整规则 |