系统建模中的最佳实践 - lethain

有相当多的人在进行系统建模，不少人认为自己是系统思想家，但相当随意地使用建模等技术。即使有可用的建模工具，我也经常走直观建模的捷径，随着时间的推移，这让我在犯善意的推理错误方面受到了很大的教育。

George Lakoff 的《Don't Think of an Elephant》和 Donella Meadows 的《系统思考》是对我影响最大两本书。

以下是我为在系统中安全思考而收集的一些规则。

1.当你的模型和现实发生冲突时，现实永远是对的

有时，您会遇到一个系统思考者，他将事物应该如何运作的直觉模型锚定在他们忽略事物实际运作的高度，他们会解释说他们的模型不应该遇到麻烦。

为了避免这个陷阱，请记住，当您的模型和现实发生冲突时，现实总是正确的。

在 Stripe，我们开发了一个模型来指导我们的可靠性战略。该模型在直觉上相当不错，但其真实世界的结果好坏参半。对我们早期模型的依附使我们分心（在收集和分类数据上花费了太多时间）并且我们在处理最重要的问题方面进展缓慢。如果我们直接参与现实教给我们的东西，而不是寻找理由无视现实的教训，我们会更有影响力。

2. 模型是不可变的，但现实不是

模型永远存在，但现实世界永远不会停止变化。随着时间的推移，这会在建模结果和实际结果之间产生偏差。安全地使用模型来指导现实世界的行为需要主动检测偏差。直观的模型很难通过这种方式进行检查，并且通常需要说服模型的创建者：他们的推理（刚好）是错误的。准确、显式的模型要容易得多：只需将预测与真实进行比较。

例如，我曾经加入一个组织，在招聘方面投入了巨大的精力，但仍然很难招聘。他们的直观模型促使他们在漏斗优化方面花费数年时间，然后引导他们改进流程。他们没有发现的是：面试官期望的不一致是招聘的最大障碍。

即使他们建立了一次性显式招聘模型，他们也只会发现其中一个问题。检测所有三个将需要定期检查模型与现实。使用显式模型，将模型结果与现实进行比较相对容易。对于直观的模型，您经常会发现自己与模型的作者发生了冲突。

3.每个模型都省略了信息；有些省略了关键信息

有许多领域很难衡量结果，在这些领域设计模型尤其困难。安全是一个特别好的例子：您如何有意义地衡量您的安全风险？我在Metrics 中探讨了无法衡量的主题，我喜欢Ryan McGeehan 关于通过预测风险来衡量安全影响的帖子。

更微妙的是只有系统的一个子集易于建模的问题，这很好地描述了我在 Uber 工作的服务迁移。

我在 Uber 加入的团队负责将单体 Python 应用程序迁移到服务架构的基础设施部分。我从那次经历中学到了很多关于运行大型迁移的知识。这里首先要强调的是，我们在实现目标方面非常成功。

这是在 Kubernetes 出来，我们在本地基础设施上工作，促进了从单体到数千个服务的快速转变。我们通过一个相当小的团队完成了这项工作，依靠自助服务工具和自动化。这证明了完成工作的团队以及系统思维的力量，可以确定解决大型复杂问题的有效方法。

然而，这是一个巨大的问题，通过迁移到大量服务而对产品工程产生的负面外部性非常高。

我进行了彻底建模以​​确定我们前进的道路的一个问题，我被模型中没有包含的挑战的程度弄糊涂了。

系统思维总是会遗漏其模型未考虑的问题。

模型必然是不完整的，制作模型的过程就是将现实简化为有用的推理工具。一旦你开发了一个模型，你只能通过回到现实的混乱中来判断它是否有用。如果您将模型的狭隘观点置于现实的实际结果之上，您的推理工具将很快成为推理陷阱。有效的系统思维来自模型与现实之间的紧张关系，如果没有健康的平衡，你将永远失去上下文。