解决方案架构师的责任和指导原则

云解决方案架构师负责指导工作负载的组件和拓扑设计，确保它们满足初始要求和长期业务目标。 此角色涵盖工作负荷的完整生命周期，随着功能的发展或组织需求的变化，调整体系结构。

作为架构师，你的角色是收集利益干系人的意见，了解业务上下文，并塑造平衡技术、运营和商业注意事项的设计。 利用开发、运营、QA、灾难恢复以及管理增量和大规模更改方面的经验，做出明智的决策。 不仅针对“快乐路径”进行设计，还针对可观测性和可支持性等作现实进行设计。 确定权衡和接受的风险，以防止隐藏的技术债务，并保持利益干系人完全知情。

本文概述了可交付结果的常见清单，以及实现可交付结果的指导原则。

架构师的职责

	可交付任务
☐	按照 5 步流程收集正确的信息、协商现实结果并保持与业务目标保持一致，使技术策略与业务要求保持一致。
☐	开发体系结构设计规范 ，并随附图表作为结构化数据包。 确保规范符合在上一任务中收集的功能和非功能要求，并包括常规、临时和紧急操作的相关规定。
☐	创建体系结构设计图 ，说明所有系统设计方面，从大致概述到网络和标识等详细维度。
☐	维护一个体系结构决策记录（ADR）， 用于捕获体系结构决策的上下文、后果和理由。 记录权衡取舍和被拒绝的选项。
☐	使用概念证明（PoCs）验证关键假设。 在完成设计之前，请使用工作代码验证高风险或新组件。 这可以防止理论设计在实践中失败。
☐	在实施 过程中与工作负荷和平台团队协作，提供有关实现顺序的明确和建议。 此协作可帮助你最大程度地提高学习能力，并从一开始就有所改进。 根据需要与利益干系人重新谈判要求。
☐	支持建模练习，这些练习 提供有关工作负荷关注点的上下文化信息。 涵盖成本、应用程序运行状况和其他方面。
☐	根据对使用模式和工作负载功能或云提供商产品/服务的更改的观察情况提供优化建议。
☐	参与审核、合规性和置信度评审 ，为有权进行评审的外部各方提供有价值的视角。
☐	在变更评审 期间担任顾问，以深入了解更改的估计成本及其可行性。

交付这些输出需要遵循架构师角色的核心原则。 以下各节重点介绍了使这些原则成为可能的关键原则。

明确业务要求

在云架构师设计解决方案之前，他们必须了解系统需要交付的结果以及影响每个决策的业务约束。 这需要创造清晰度，并与利益相关者保持一致，共同围绕预算、时间表、合规性义务、绩效预期和增长计划进行努力。 如果没有这个基础，设计过程可能会螺旋式演变成无休止的修订，并导致沮丧和失望。

建筑师提出深入的问题，将请求建立在现实基础之上，并引导对话朝着实现目标的方向发展。

制定决策框架

首先提前确定关键决策。 借鉴过去的经验，预测选择最重要的地方，并确保清楚地记录这些选项。

到了该作决定的时候，要慎重。 权衡约束、折衷、努力、可逆性和风险。 决策树和基准等工具可以指导你，但它们不会取代你的判断。 将本指南与概念证明和测试的证据相结合，做出明智的选择。

记录体系结构决策记录（ADR）中的每个决策，包括推理和理由。 确保决策在系统中传达、应用和反映。

通过概念验证跟进实现过程。 注意结果并向他们学习。 请注意，那些没有做出的决策引入了风险，并利用这些见解来指导未来的架构工作。

了解云设计模式

云设计模式应触手可及。 作为架构师，你需要快速识别它们，并本能地应用它们。

查看功能和非功能要求时，请将它们映射到正确的模式。 使用经过验证的云设计模式来指导工作负荷、简化决策、降低风险并加速交付。 这些模式掌握得越熟练，就越能在设计中自然地体现其效果。 Well-Architected 框架为其支柱建议以下模式：

• 支持可靠性的体系结构设计模式
• 支持安全性的体系结构设计模式
• 支持成本优化的体系结构设计模式
• 支持卓越运营的体系结构设计模式
• 支持性能效率的体系结构设计模式

前瞻性思维

为变革而设计，而不仅仅是为了当前要求。 预测设计中的演变比改造实时系统要便宜得多。 专注于灵活性，避免设计障碍，因为它们可能会阻碍未来的增长，但要设定切实可行的界限。 成功来自于留出空间来适应和改进，同时认识到某些设计决策仅在一定范围内有效。 需要注意的常见方面：

• 预计工作负荷使用量可能会随着时间推移而增加或减少。
• 提前规划可能影响工作负荷的潜在未来法规。
• 针对可能的区域扩展和不同的地理要求进行设计。
• 不要使用已弃用的组件，并仔细评估使用预览功能的风险。

可支持性设计

设计工作负荷时，请考虑从三个角度进行支持。 确保系统在您的云提供商支持的配置内运行，以避免在寻求平台支持时发生中断。 提供操作可见性，使团队能够快速了解和响应故障。 最后，考虑到客户支持的设计，使支持团队可以轻松调查问题并协助用户不受摩擦。

保持动手并不断学习

不要成为象牙塔建筑师，他只谈抽象和理论。 体系结构会因为它建立在好奇心和实地动手经验的基础上而赢得尊重。 决策应基于你通过试验、解决问题和直接处理技术所学到的知识。 探索不熟悉的工具，构建原型，并通过这样做来学习。 通过培训和认证加强基础，并通过与同行和加入社区（如黑客马拉松等实践活动）互动，拓宽视野。

还可以通过提出以下问题来自我评估：

• 我解决什么体系结构问题，为什么对业务很重要？
• 我正在解决现有设计或文档中的哪些差距或缺点？
• 哪些证据或分析支持我建议的方法？
• 我发现了哪些权衡、风险或设计瓶颈？
• Well-Architected 框架的哪些支柱在此设计中最为相关，为什么？

协作以取得成功

作为架构师，您不能单独工作。 使用云提供商提供的专业知识。 大多数提供商希望您的工作负载成功，并提供有价值的资源，包括体系结构评审和设计咨询，并可直接接触经验丰富的解决方案架构师。 充分利用这些关系来验证设计、发现盲点，并增强整体方法。

在许多组织中，工作负荷团队依赖于平台团队进行共享基础结构和服务，类似于 Azure 登陆区域模型。 当体系结构依赖于此合作关系时，请与平台团队密切合作，以提供满足长期目标的解决方案。

在设计方法中有条不紊

纪律严明的方法会导致更好的体系结构。 使用 Azure Well-Architected Framework 与其他已建立的体系结构框架（例如 Open Group Architecture Framework（TOGAF）结合使用来指导你的过程。 他们的原则和清单可帮助你做出一致、明智的决策。 使用决策树和参考体系结构等资源进行补充，以进一步加强设计决策。

为这些框架和你自己的技术（例如思维映射或结构化决策日志）支持的每个工作负荷定义可重复的过程。

架构与设计一样注重清晰。 仔细考虑你如何做出决策、表面权衡和传达你的理念，以便利益干系人了解你正在走的道路。

后续步骤

开始处理架构师职责清单的第一项。

符合业务需求