系统思维：运用系统思维识别存量、流量、反馈和爆炸半径，这是程序员开始假装自己是生态学家的节奏？
1958年，数学家约翰·怀尔德·图基（John Wilder Tukey）在印刷品中使用了“软件”一词，以区分书面指令和物理硬件（图基， 《美国数学月刊》，1958年1月）。他是创造了这个术语，还是仅仅推广了它，至今仍有争议，但它所代表的转变是毋庸置疑的。
此后几十年，软件的扩展已远远超出了这一定义。如今，它已成为一个由语言、框架、流程以及日益增长的机器智能组成的复杂网络。它不再仅仅是技术产物；而是一个不断发展的社会技术生态系统，人与技术在其中不断相互影响。
许多人尝试叙述和解释软件构建的过程。这篇文章则从不同的角度出发：系统思维。我想展示软件的核心是如何像一个活的系统一样运作的，以及如何通过系统思维的视角理解它，帮助我们更清晰地理解技术和人为的复杂性。
我借鉴了基础系统思维的著作：Donella Meadows 的《系统思维》（2008）中关于存量、流量和反馈的语言。我的目标不是重新教授他们的著作，而是将其融入软件的概念中。
系统思维词汇
以下是我在本文中使用的关键系统思维术语。
- 存量Stock： 代表系统记忆或状态的某种事物的积累；它只能通过流动来改变。
- 流动 ： 随时间推移库存增加或减少的变化率；只有流量会改变库存。
- 流入 ： 增加库存的流量。
- 外流 ： 减少库存的流量。
- 来源 ： 流体起源于系统边界之外的点。
- 下沉 ： 系统边界之外的流终止点。
- 瞬态流 ： 指在系统边界内发生并完成且不改变库存的操作（例如，向外部提供商发送电子邮件）。实际上，软件总会留下痕迹，但这些影响发生在我们正在分析的系统之外。
- 过程 ： 转化投入并影响存量流量的机制。
- 反馈回路： 输出作为输入反馈的结构，影响未来的行动（强化或平衡）。
- 平衡反馈回路 ： 目标搜索循环可抵消偏差，使库存稳定在目标附近。
- 强化反馈回路 ： 放大变化的循环，产生指数增长或衰减。
- 延迟 ： 反馈回路中信息处理和执行所需的时间。延迟可能会破坏系统的稳定性。
从浴缸到系统视角
让我们从经典的系统思维示例——浴缸开始。浴缸中的水是存量，水龙头创造了流入。你通过观察水位并调整水龙头形成了反馈环路。当水位过高时，马桶浮球会自动关闭水流，这就是平衡反馈环，维持水位稳定。你如果在放松的状态下增加水流，便会形成一个强化反馈环。排水口则是流出。
现在，我们将这种思维方式应用到软件上。
软件最简单的形式是接受输入、处理它并生成输出。让我们具体化一点：一个接受用户输入并发送电子邮件的软件。这“发送邮件”动作是一个瞬态流动——它一次性发生，离开你的系统边界，并不会在系统内留下任何记忆。
添加记忆：
你的第一个存量接下来，我们为系统添加记忆。数据库是完美的工具。我们的软件使用数据库来保存用户数据。这一行为创造了一个流入，增加了数据库中用户记录的数量。现在，数据库成了系统中的第一个存量——一个信息的积累。
如果用户选择删除数据，这会触发一个流出，删除数据库中的记录。
环境上下文
软件从来不是在真空中运行的。硬件、操作系统、网络等外部环境会引入自己的触发器，如中断或错误。假设我们的软件记录这些中断，这就引入了第二个存量——日志文件。操作系统中断触发一个流入，写入日志，增加日志的大小。
第一个反馈环：
自我调节每当一个新的存量出现在系统中时，我就会立刻开始寻找反馈环。这个存量的变化将会引起谁或什么的反应？
在这个例子中，日志文件的大小是有限的。如果日志文件过大，可能会导致应用程序崩溃。为防止这种情况，软件必须通过平衡反馈环来进行自我调节。它会监控日志文件的大小，当达到阈值时，触发日志轮转——流出的行为，减少存量。
强化反馈环：放大变化
到目前为止，我们的例子都是关于系统自我稳定的，但系统也可能会有放大变化的环路。想象我们添加了一个新功能——每个新用户可以邀请三位朋友。这会创造一个强化反馈环：用户越多，邀请的新用户也越多，从而导致“用户”存量的指数增长。
这是一个良性循环，但强化反馈环也可能带来恶性影响。例如，服务器负载过高开始失败请求，导致客户端重试，进而增加负载，最终导致崩溃。
系统演变：压力下的队列
现在，我们来看看在压力下系统如何演变。流量激增，虽然数据库能应对，但同步发送电子邮件的速度太慢，用户开始看到失败。一个常见的解决方法是添加队列，这就引入了一个新的存量，并且出现了不同类型的反馈。
“爆炸半径”
这里，我要引入一个新的概念——“爆炸半径”。请注意，这并不是传统系统思维中的术语。爆炸半径指的是当一个系统组件失败、改变或受到威胁时，影响的范围和程度——包括所有直接或间接受影响的用户、流程、系统和业务功能。这一问题迫使我们去描绘出影响的范围，看到所有被我们的决策所连接的系统和人类生活。
实践应用：
如何用系统思维解决问题在设计、改变或故障排查系统时，你可以问自己以下四个问题：
- 什么是存量？确定系统中每个信息或工作的积累点。
- 它们如何被调节？找出哪些反馈环（无论是自动的还是人工的）在监控这些存量，并保持它们的平衡。
- 延迟在哪里？精确找出反馈环中信息可能延迟到达或采取行动的地方，通常这是你需要优先关注的地方。
- 爆炸半径有多大？确定当系统失败或变化时，它的影响范围有多大，哪些用户、团队、流程和下游系统会受到影响。
这种视角不仅有助于发现技术问题的根本原因，还能让架构师和开发人员能够更有效地进行系统设计和故障排查。