业务需求设计
 收集业务要求，重点关注工作负载须具有的效用。 |
|---|
业务要求由业务利益干系人和工作负载架构师在合作的基础上共同确定。 在各方面均须作出适当折中，以确保商定的要求是切实可行的，且工作负载须满足的可靠性目标能够最终实现。 所议要求须涵盖特定于工作负载的用户体验、数据、工作流和特征。 要求过程的结果必须明确说明预期。 在给定了投资的情况下，这些目标必须是可实现的且能够沟通传达给团队。 必须将目标记录下来，根据目标来选择技术、促进实施和操作。
示例场景
Contoso Insurance 要开发一个用于处理投保人索赔的 Web 应用程序，目前处于早期设计阶段。 大多数核心用户和系统流已确定，工作负载团队也已确定多个将构成应用的 Azure 服务：Azure 应用服务、Azure SQL 数据库、Azure AI 服务、Azure 事件网格和 Azure 逻辑应用。
确定可靠性目标
通过针对各个组件、系统和用户流以及整个系统设定相关指标来量化成功。
指标对预期进行量化。 可借助指标了解复杂度，并确定用于支持相关复杂度的下游成本是否在投资限制范围内。
目标值表示理想状态。 可以使用这些值作为测试阈值，帮助检测与该状态的偏差以及回归到目标状态所需的时间。
合规性要求还必须具有针对范围内的流的可预测的结果。 为这些流确定优先级可帮助将重点放在最敏感的区域。
Contoso 面临的挑战
- 工作负载团队希望确保他们确实在优化资源的使用方式以使工作负载更可靠。
- 他们将工作负载分解为流，并根据流的重要性对流进行了分级。
应用方法及结果
- 由于医生和患者依赖于流的可用性，该团队决定“索赔提交及审批”流在工作负载中的可靠性要求最高。
- 工作负载团队确定了用于支持此流的组件，并确定了实现目标所需的可靠性度量指标。
了解平台承诺
了解云平台提供的有保证的可靠性指标，并考虑服务的限制、配额和容量约束。
服务级别协议 (SLA) 因服务而异。 服务和功能并非均以同等方式涵盖在内。 充分了解覆盖范围和限制有助于检测偏差及构建复原能力和恢复机制。
Contoso 面临的挑战
- 工作负载团队和利益干系人已确定，应用的数据需要有确保的恢复时间目标 (RTO)，该目标不能超过 30 秒，以此支撑其“索赔提交及审批”流的重要性。
应用方法及结果
- 查看 Microsoft 发布的 SLA 后，团队发现他们需要部署带活动异地复制功能的业务关键层才能实现此 RTO 目标。
确定依赖关系及其对复原能力的影响
将工作负载分解为组件时，请确保记录了所有依赖关系（无论是企业内部还是外部的依赖关系），并确定依赖关系出错会如何影响流
持续了解其他团队或第三方开发的有依赖关系的基础结构、服务、API 和函数有助于确定工作负载是否可在没有相关依赖关系的情况下运行。 这还有助于了解级联故障和改进下游操作。 当使用易受故障影响的外部服务时，开发人员可实现可复原的设计模式来处理可能发生的故障。
Contoso 面临的挑战
- “索赔提交和审批”流依赖于一个由 Contoso Insurance 中另一个部门托管和管理的小型引用数据集。
- 数据集在每天的常规工作时间内会更新数次。
- 应用可容忍引用数据存在一定程度的过时，但数据必须始终可供应用使用。
应用方法及结果
- 工作负载团队咨询了支持引用数据集的团队，了解到数据集的可靠性目标低于要使用数据集的流的目标。
- 团队在积压工作中增添了设计任务，用于添加数据集的一个本地缓存和一个每晚更新缓存的后台作业。 此解决方案不会影响设计允许的过时容忍度。