使技术策略与业务需求保持一致

作为云架构师，你的第一项任务是建立清晰性。 在做出有意义的架构决策之前，您需要了解系统必须实现的目标、所服务的用户，以及必须遵循的约束条件。 你需要清楚地了解业务设置的预期结果和边界。

每个决策都由实际压力决定：预算、交付时间线、合规性规则、性能预期和服务级别承诺。 这些不是可选注意事项。 它们是设计必须满足的条件。

如果你不了解这些因素，则系统很有可能发生故障。 有时要求从假设开始，而不是真正的需求。 例如，可能会有请求的功能列表，但不会列出将给系统带来压力的流量模式。 明年的增长呢？ 已经向客户做出了哪些承诺？

这是你在这里发挥作用以带来清晰度的地方。 你需要仔细倾听，询问请求是否存在的原因，并将实际需求与早期假设分开。 你将对话引导回目标，而不是落实。 当请求不切实际或不对齐时，需要提出仍可实现所需结果的替代方案。

本文介绍如何按照 5 步过程执行此作。 它使用一个示例来说明如何在设计任何内容之前收集正确的上下文、提出正确的问题并构建共享理解。 这样，就可以创建不仅在技术上健全，而且符合实际动机、业务压力和长期目标的体系结构。 如果你不熟悉此角色，我们建议从 解决方案架构师的基本指南 开始，获取角色概述以及定义成功的内容。

倾听：捕获干系人请求

在云架构师加入新计划时，业务利益干系人通常对他们想要的内容和通常的预算约束有远见。 产品所有者、业务分析师和领域专家可能已经记录了要求，其中一些见解可能很有价值。 将它们视为请求而不是要求。 在尚未了解基础动机时，业务团队常常提前进入决策模式，提出功能、工具或技术方面的请求。 此外，早期输入也容易受到扭曲的判断，其中小细节可能会过度强调，核心需求被忽视。 作为架构师，确定工作负荷缺乏明确性、假设被误认为要求的位置，以及信息不完整或缺失的位置。

每次建筑设计交流都从倾听开始。 在这个阶段，你的工作不是批评或解决。 这旨在吸收期望的结果，并获得动机的早期迹象。 你可能会发现自己说“请详述”。记录所述请求、其背后的假设以及任何嵌入的解决方案偏好，这通常显示为“我们需要构建 X”之类的语句。

请考虑此常见方案。 一个业务团队说，“我们需要 100% 运行时间。起初，这听起来像是一个简单的要求。 然而，他们可能将高可用性误认为高质量，或者对最近的故障做出冲动反应，或者在没有适当分析的情况下，盲目跟随竞争对手采用的趋势。

在此步骤中，请务必尊重业务观点，并且不会忽视业务利益干系人的担忧。 善于倾听可以建立信任，为发现真正推动请求的因素奠定基础。

探究：了解动机

在对业务要求的内容有基本了解后，下一步是问“为什么？” 并重复这样做。 目标是进行探查，直到真实需求显露出来。 了解请求背后的压力、约束和激励。 同样重要的是了解解决方案如何适应更广泛的业务环境。 如果不了解动机，就有可能瞄准错误的目标。 你可能会提出如下问题：

• 是推动收入还是主要支持业务？
• 它会影响组织的核心部分，还是解决利基问题？
• 这是否解决了生产问题？
• 它是由竞争或市场转变推动的吗？
• 是否需要满足合规要求？
• 这是更广泛的战略方向的一部分吗？

动机很重要，因为两个类似的请求可以表示非常不同的意图。 满足法规截止时间所需的功能需要不同于一种旨在解锁新增长机会的体系结构方法。

返回到该示例，探测显示最近中断导致订单丢失。 竞争对手现在宣传实时订购可用性，高管们担心品牌受到另一次失败的损害。 此外，当结账系统下线时，客户支持会面临过载。

此时，“100% 运行时间”具有不同的含义。 真正的动因不是追求完美，而是业务连续性对于那些关键收入流的重要性，尤其是在结账环节。

在此步骤中，你未决定解决方案。 你正在发现请求背后的力量，以便可以在正确的业务上下文中定位体系结构。

阐明：将请求转换为要求

一旦动机明确，下一步就是阐明业务的实际需求。 这就是你将业务动机或请求转化为具体结果和可衡量要求的地方。

在此示例中，深入了解并就对用户的影响达成共识，例如：

• 哪些用户流必须始终可用？
• 如果辅助流暂时关闭，会发生什么情况？
• 哪些功能会影响收入？
• 什么是可接受的降级模式？

在此步骤中，“100% 可用性”分解为流级别要求：

• 订单下达 必须高度可用。 停机时间直接影响到收入。
• 目录浏览。 可以短暂地性能下降，而不会造成重大损害。
• 订单历史记录。 可以容忍计划内维护。

请注意，这些仍然是业务成果，但尚未选择体系结构。 阐明需要重新定义“使所有内容始终可用”到“确保生成值的流的连续性”的要求。

某些业务要求隐式地带来了需要明确讨论的其他要求。 可能会遗漏数据驻留、安全标准、数据保留或其他行业标准等要求，因为利益相关者可能会假设这些要求已被理解，或未意识到它们的适用性。 在流程的早期识别并显式记录这些要求。

评估：测试可行性、约束和权衡

定义要求后，下一步是评估在实践中和固定和灵活的约束中如何满足这些需求。 此步骤涉及技术和作可行性、成本影响、风险以及与组织标准保持一致。 这是你带来工程判断和建筑经验的地方。 首先提取约束并定义成功。 专注于真正重要的事情，避免过度工程，并知道何时一个更简单的解决方案就足够了。

继续使用高可用性示例，列出权衡因素，例如：

• 成本：多区域主动-主动架构使基础设施成本翻倍。
• 工程复杂性：跨区域状态复制并不简单。
• 安全性和符合性：多个区域引入了数据驻留问题。
• 运营努力：24/7 值班轮换和复杂的切换容错过程。

这就是每个答案不可避免地以“它依赖”开始的点。评估通常暴露了企业想要的内容与实际内容之间的不匹配。 它有助于企业理解实现“100% 正常运行时间”的实际要求。 你可能会发现，只有结账流程可以证明在多区域进行部署是合理的，而目录和订单历史记录则没有这个必要。 你可能还会发现风险，例如不成熟的团队功能、过度估计的好处或低估的成本。 还可以发现应用替代方法的机会，这些方法可以更好地平衡成本、复杂性和可靠性。 例如，当权衡适合该流程时，在 CDN 中缓存目录可以达到这种平衡。

你还没有选择技术。 此步骤与定义边界有关。 这包括映射约束、突出显示利弊，并将解决方案空间缩小到满足实际条件下明确要求的方法。 采用协作方法统一观点，并就前进道路达成一致。

建议：建议技术策略

了解可行性和权衡后，下一步是推荐符合实际业务需求的技术选择和其他决策。 这意味着，将发现期间捕获的信息转换为清晰、可执行的方向，以使企业期望的内容、实际需要的内容以及您建议构建的内容各环节形成闭环。 每一项建议都是一个谈判、妥协和一个机会，使它随着时间的推移变得更好。

建议应记录并涵盖以下方面：

• 解决阐明的要求
• 反映评估期间确定的约束和权衡
• 向利益干系人明确传达选项及其影响

返回到运行时间示例时，建议可能如下所示：

结账功能应在多区域活跃-活跃配置中运行，以保护收入。 目录服务可以在单个区域内运行，并使用只读副本来增强弹性。 订单历史记录可以保留单区域，并具有计划内维护时段。 此方法将满足连续性的要求，同时避免不必要的重复和成本。

尽管这听起来像是最后一步，但它实际上是迭代的，标志着设计过程的开始，其中决策是通过利益干系人反馈、权衡讨论和在每个设计里程碑上的协议进行优化。

预期结果

在此阶段，你已完成倾听和要求收集过程，与业务部门分享了你的发现结果，并就目标、范围以及过程中发现的任何改进达成一致。 这些见解自然会导致对原始业务需求的调整和早期设计注意事项的形成。 有了这种明确性，你现在有了帮助生成清晰且有基础 的功能规范所需的信息。 尽管产品利益干系人通常拥有本文档，但架构师通过帮助塑造捕获的信息结构并确保强大的技术设计所需的清晰度，从而发挥重要的支持作用。

本文档定义工作负荷或功能必须实现 的内容 及其重要 原因 。 它应该描述正在解决的业务问题，其中可衡量的结果定义了成功。 这些元素构成了指导所有后续技术设计工作的基础。

此阶段开发良好的功能规范应包括：

• 明确定义范围和范围外的内容，提供减少歧义并防止范围爬行的边界。
• 将用于评估更改并将其绑定到业务目标的指标和成功标准。
• 详细用户流程图，其中包括在需要时支持的低保真模型，并包括预期的错误或异常处理。
• 与无障碍访问、合规性、性能、隐私或安全性相关的任何要求。
• 定义的推出策略，例如分阶段部署或目标 beta 版本。

体系结构从来不是一项已完成的活动。 考虑多个时间范围：第 1 天、近期增长和长期规模。 规划在增长阈值可能需要重新审视决策和取舍的时刻，同时避免过早过度设计。 初始设计可以捕获最少的可靠功能，但每个后续周期都会根据观察到的使用情况、转移优先级和新业务目标优化体系结构。 更新此规范和其他规范以体现其演变，确保所有利益相关者始终保持一致。

交付规范是一个持续、协作的过程。 架构师在整个实施过程中仍积极参与业务利益干系人和技术团队，帮助确保正确解释设计、管理风险以及生成的系统符合业务目标。 有关详细信息，请参阅 与工作负荷和平台团队协作。

后续步骤

现在，你已就业务要求达成了共识，并且它们已记录为功能规范的一部分，开始编写描述设计选择的详细技术规范，并附带图表。

开发体系结构设计规范