为今天构建。为明天规划。为失败规划。
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 5 个模块，共 7 个，属于 Data Architect 课程的第一章像数据架构师一样思考。每个模块都可以单独阅读。 上一篇：架构是权衡的艺术 · 下一篇：了解你的工具：九个问题
**本模块回答的问题：**如何在满足今天需求的同时，为增长和失败做好规划？
架构中最容易犯的错误之一，是只为摆在眼前的需求做设计。我们有一个项目、一份待办列表和一些需求。我们构建出满足它们的东西。它能用，我们宣布胜利。六个月后，业务变了，或者数据增长了，或者另一个业务部门也想用它，或者我们收购了一家公司，或者有新系统需要集成，或者出了一个没人预料到的故障。
这些都不该让架构师感到意外。我们无法预测会发生的一切，但我们可以在设计时就知道总会发生些什么。这就是为什么我用三个视角来审视架构：
为今天构建。 为明天规划。 为失败规划。
三个缺一不可。
为今天构建
Section titled “为今天构建 ”架构从我们实际面对的问题开始。这听起来理所当然，但架构师可能犯一个与短视相反的错误：过度架构。万一我们收购十二家公司、有十亿客户、扩展到 40 个国家、每个系统都需要实时集成呢？也许吧。但这些是真实的可能性，还是我们在凭空制造问题？架构不是构建我们能想象到的最复杂的系统，而是构建合适的系统。
所以从今天开始：业务需要什么，实际的数据量、用户数和事务量，数据多久变一次、要多快流转，谁需要访问，数据从哪里来、到哪里去。最重要的是：**为什么？**这些答案给了我们可以落到设计上的具体东西。
寻找隐含的需求
Section titled “寻找隐含的需求 ”别人交给你的需求，不一定是你的全部需求。几乎总存在隐含的需求。
业务方说：“我们需要把客户数据放进 Salesforce。”好的。那么就得有人拥有这些数据，并决定它必须多新。我们需要知道源系统宕机时会怎样，同步失败时我们怎么发现，Salesforce 和源系统不一致时以哪边为准。我们需要一个保留期限、一个访问模型、一个关于敏感字段的决定，以及一种纠正坏数据的方法。
这些都不在用户故事里，但它们仍然都是架构。成为架构师的很大一部分，就是学会识别那些还没被问出来的问题。
了解你的数字
Section titled “了解你的数字 ”我一直督促架构师去量化。不要告诉我数据很多，告诉我有多少。一万、一千万、一亿、十亿？这是截然不同的架构。不要告诉我集成运行得很频繁：每小时一次、每分钟一次，还是每秒一千次？不要告诉我我们增长得很快。有多快？
在没有更好的数字时，我的基准是每年增长 30%。这不是预测，而是一种倒逼手段。如果有人告诉我今天有 1,000 万条记录，我不希望讨论停在 1,000 万。按每年 30% 计算，明年大约 1,300 万，后年 1,700 万，再下一年大约 2,200 万。现在我们来谈设计。如果业务方告诉我 30% 太离谱，很好：给我真实的数字。重点是让增长成为架构讨论的一部分。
我把这叫作 Steve 的“零的个数”（Steve’s Number of Zeros）。多一个零就可能彻底改变你的架构。一万、十万、一百万、一千万、一亿：功能没变，需求也许也没变，但架构可能会变。
还记得模块 1 里的预约吗？我们给它配上真实的数字。超过 1,200 个网点，每个网点每天 100 个预约，每周营业六天，一年大约 305 天。第一年就超过 3,600 万个预约。每次到店产生两条记录，所以超过 7,300 万条记录。再保留五年历史，每年增长 30%，就超过 6.5 亿条记录了。同样的功能，同样的需求。多了几个零，就是截然不同的架构。
为明天规划
Section titled “为明天规划 ”理解了今天，我就会往前看：哪些东西有合理的可能会改变？数据量是其中一部分，但明天不只是更多，也可能意味着不同：更多的产品、业务部门和国家；不同的隐私要求；新的渠道和集成；一次合并或收购；新的主数据策略或分析平台；一个消费原本只为人类设计的信息的 AI 智能体。
这就是为什么我如此在意架构能否通过添加而不是不断修改来成长。如果业务增加了一个产品，模型能容纳吗？如果另一个系统需要这些数据，我们能干净地开放出去吗？如果数据量猛增，我们有路可走吗？如果业务结构变了，我们会不会不得不把数据模型拆掉重来？我们不是要完美地预测未来，而是要避免把自己逼进死角。
不要今天就构建明天
Section titled “不要今天就构建明天 ”这里需要平衡。为明天规划，不等于今天就构建明天的系统。如果我们现在有 10 万条记录，五年后可能有 1 亿条，这并不意味着现在就要构建 1 亿条记录的架构。那可能带来我们暂时还不需要的成本和复杂度。
我想得到回答的问题是：今天的架构能否演进成明天的架构？如果我们能从简单开始，同时有一条清晰的前进路线，这往往比提前好几年支付复杂度成本要好。危险不在于从小处起步，而在于起步的地方无路可走。
为失败规划
Section titled “为失败规划 ”现在说说没人喜欢谈的部分：东西会出故障。我从没设计过这样一个系统：每个组件永远可用，每个集成都成功，每个用户都输入完美的数据，每个外部系统的行为都和文档写的一模一样。所以不要去设计那样的系统。
问一问什么可能出故障，再问一问出故障时会发生什么。一个集成超时。一个 API 拒绝了请求。一次夜间加载处理 80 万条记录，其中 20 万条失败。一个源系统宕机。一个用户输入了无效数据。一个外部标识符出现了两次。一个上游系统改了某个值的格式却没改字段名。一个流程在一个系统里成功，在另一个系统里失败。这些不是罕见的边缘情况，这就是生产环境的样子。
部分成功仍然是你需要弄清楚的失败
Section titled “部分成功仍然是你需要弄清楚的失败 ”部分失败在数据架构中尤其危险。想象一下搬运一百万条记录，流程报告说已经完成。很好。但到达的是一百万条，还是 999,997 条？少了的是哪三条？也许有 20 万条失败了，有些被创建了两次，或者全部到达了但有些字段转换失败。
“作业已完成”不等于数据是正确的。数据架构师会考虑对账：我们怎么知道本该发生什么、实际发生了什么，以及两者的差异？我们又该怎么处理？
系统变复杂时，我是这样做的。记录从 A 到 B，从左到右。然后 B 回传一些东西：对它收到并保存的每一条记录发一个确认。现在 A 就可以把发出去的和收到确认的进行比较。如果每条记录都有确认，这次运行就成功了。如果缺了任何确认，那就是没成功，不管作业状态怎么说，而且我们确切知道要去追哪些记录：重试它们，转给人处理，或者发出告警。
优雅地失败
Section titled “优雅地失败 ”出故障时，我想知道系统接下来做什么：会不会重试，是不是自动重试；同一笔事务被处理两次会怎样；失败的记录去了哪里，好的记录能否绕过坏记录继续流动；谁会收到告警，带着什么信息，他们如何重放这次失败；用户如何得知出了问题。
最重要的是：**我们能否在不让问题变得更糟的情况下恢复？**一个会制造重复数据的重试策略，算不上什么恢复策略。好的架构假定会失败，并给我们留一条回来的路。
监控重要的东西
Section titled “监控重要的东西 ”没有监控的失败规划算不上真正的规划。如果一个集成在凌晨 2 点失败，直到三天后客户打来电话才有人发现，那我们并没有运维架构。我们只有希望。
决定哪些东西需要可观测：流程运行了吗，花了多长时间，处理了多少条记录，多少成功、多少失败？数据量是否突然和平常不一样？积压是否在增长，错误是否在增加？架构并不在部署成功时结束。明天得有人运维这个系统，而这也是设计的一部分。
朝三个方向思考
Section titled “朝三个方向思考 ”在本课程的其余部分里，持续运用这三个视角。设计数据模型时：今天能用吗，明天能成长吗，数据错误或不完整时会怎样？设计集成时：它能搬运今天的数据吗，能应对明天的数据量和系统吗，一端宕机时会怎样？面对大数据量时：今天有多少，数字往哪里走，一次大型操作只部分成功时我们如何恢复？
技术每章都在变，问题不变。
架构存在于时间之中
Section titled “架构存在于时间之中 ”开发人员有时可以看着一项需求问：“这能用吗？”架构师必须问得更多：它今天能用吗，明天还能用吗，当它完全不能用时会怎样？这三个问题把我们从实现带进了系统的整个生命。
你不会预测到每一项未来的需求，也不会阻止每一次失败。那不是目标。目标是构建一个与我们今天所知相称的东西，给明天留出路，并在现实不配合时有一个计划。
**为今天构建。为明天规划。为失败规划。**我们会一次又一次地使用这三个视角。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 真实的数据量和增长是多少，哪些数字会改变设计。
- 业务方还没说出口的隐含需求有哪些。
- 今天的设计如何演进成明天的设计，而不是今天就构建明天的系统。
- 出故障时会发生什么：恢复、对账和监控。