工作负荷体系结构设计规范

工作负荷体系结构设计规范是 描述设计选择的详细规范，并附带图表。 设计选择必须满足功能和非功能要求，并包括常规、即席和紧急操作的规定。

有关关系图的信息，请参阅 体系结构设计图。

工作负荷体系结构设计通常扩展，从应用程序设计和云服务选择的进度开始。 这些阶段相互通知。 组合的应用程序和基础结构设计必须满足所有要求。

实现满足所有要求的解决方案是 利益干系人、开发人员、测试人员、运营团队和产品所有者之间的协作努力。 设计过程应涉及明确和协商的优化要求。 此过程是迭代的，通常需要多次评审。

建议将设计与 Azure 架构良好的框架基本指南（包括设计原则和建议指南）保持一致，并承认权衡。

最终，工作负荷体系结构设计规范由工作负荷开发团队实现，因此必须明确明确和明确。 该规范应随时可用，并随工作负荷的文档一起存储。

功能规范

工作负荷的功能规范详细说明了系统或正在开发的功能或功能的原因，但不包括实现。 本文档必须说明存在的当前问题，以及此功能或系统将如何改进该体验。 本文档捕获了大部分业务要求。

架构师可以帮助塑造本文档，但主要是产品所有权的功能。 架构师应帮助设计此规范中捕获的数据。 这种参与可确保功能规范驱动高效且高效的技术设计。

下面是本规范中应介绍的几个示例主题。

• 除了详细说明此设计的范围外，还明确说明范围之外相邻的担忧。 设置清除范围可以通过定义功能周围的边界来减少范围爬行。

• 包含有关如何测量此更改的详细信息会很有帮助。 需要收集哪些度量值，以及这些度量支持哪些业务目标。

• 应清楚地描述用户流。 低费力模拟也很有帮助。 如果错误处理情况对于这些流很重要，请确保描述的预期行为。

• 始终包括对辅助功能、合规性、性能、隐私或安全性的任何特定要求。

• 包括任何计划的推出策略。 例如，“在决定完整版本之前，此功能将适用于我们的 beta 版用户两个月。

避免此规范中的特定技术实现详细信息。 这些功能规范将驱动架构师创建的技术规范。

技术规范

技术规范描述如何基于功能规范中所述的范围和目标。 此规范旨在使工程团队在实施过程中用作记录计划。

在此规范中包括以下项：

• 技术决策，包括：购买、生成、重复使用、扩展或停用。
• API 和数据协定（架构），包括向后兼容性实现策略
• 推出和回滚实现详细信息
• 独特的安全开发生命周期（SDL）和隐私实现
• 测试计划
• 关键监视和警报信号源
• 已考虑的替代设计

技术规范将推动工程工作。 工程工作项主要基于此规范的内容创建。 实施团队是指工作项、技术规范和功能规范，以确保最终结果同时满足功能和非功能要求。

灾难恢复计划

为了满足工作负荷的可靠性要求，架构师需要设计可在目标恢复时间目标（RTO）和恢复点目标（RPO）目标内恢复的系统。 体系结构设计规范必须包括恢复计划。 此计划必须涵盖涉及的体系结构组件、故障转移机制以及对用户和数据流的影响以及操作建议。 它应描述设计如何满足哪些恢复目标。

虽然初始计划预计将根据演练和事后评审的见解而发展，但架构师有责任为所有新体系结构提供初始计划。

安全性和符合性文档

架构师负责设计符合相关安全性和合规性约束的解决方案。 设计项目必须强调设计中包含的功能以支持这些要求，并在无法直接满足要求时确定任何必要的补偿控制措施。

一致性

使用模板记录工作负载的各种规范。 读取规范时，一致性可帮助利益干系人、责任方和实施团队。

确保规范具有关键元数据字段，例如：

• 状态：状态为 “草稿”、“ 正在审阅”和 “已批准”。
• 工作项链接：指向团队积压工作项中主要工作项的链接。
• 关键交叉链接：指向支持规范的相关规范或其他文档的链接。
• 关键人物：列出涉及的关键决策者的姓名的位置。 此列表可能包括以下角色：业务分析师、业务合作伙伴、技术主管以及签署规范的产品所有者或潜在顾客。

后续步骤