你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用流优化工作负载设计

项目
01/31/2024

本文介绍使用流对工作负载进行有针对性的优化。工作负荷的不同组件有不同的要求和重要性级别。通过将工作负荷分段为流，可以确定工作负荷的不同部分的优先级，并更好地使工作负载投资与每个流的重要性保持一致。

此工作负载优化过程是迭代的，涉及三个关键步骤： (1) 定义工作负载中的流结构， (2) 定义技术要求; (3) 设计流以满足要求 (见图 1) 。

图 1：使用流优化工作负载的过程。

定义流

在定义流要求之前，需要了解流的业务驱动因素。定义流的先决条件是标识其支持的业务流程和用例。了解先决条件后，可以开始记录流。

了解先决条件

流是支持工作负载功能的操作序列。有两种主要类型的流：用户流和系统流。用户流确定用户交互。系统流确定工作负载组件之间的通信。流支持业务流程和用例。工作负载由多个用例组成。在记录流之前，需要确定流支持的业务流程和用例 (见图 2) 。

图 2：业务流程、用例、流和工作负载之间的关系。

确定业务流程

业务流程是满足业务需求 (阶段) 的一系列操作。流确定用户或数据完成业务流程的每个阶段所采用的顺序。例如，在线销售产品是一个业务流程。此业务流程中的阶段可能是在线列出产品、接收订单和交付产品。

确定用例

用例定义流的功能要求。在确定流的技术要求之前，需要确定并了解流支持的用例。每个用例都应支持业务流程中的一个阶段 (见图 2) 。用例应定义以下属性：

目的：明确说明任务或目标，例如启用在线购买。这种清晰度指导功能设计，并为流设计设定明确的目标。
关键性：评估用例的重要性，范围从例程到关键。分配给用例的值指示流的优先级和设计。高价值用例可能需要增强的错误处理、性能优化或用户体验注意事项。
使用者：确定用户 (客户、员工) 还是系统组件的主要使用者。此分类确定是用户流还是系统流，并影响设计。
事件：定义启动和结束用例的触发器或条件。这些事件定义流的边界。
执行：了解用例的操作频率和可变性，以预测系统负载。必须设计一个流来处理不同的执行方案。
依赖项：识别与其他用于风险管理的用例的相互依赖性。识别用例的依赖项有助于设计与其他系统部件顺利集成的流。你需要确保必要输入的可用性以及输出与后续进程的兼容性。

记录流

使用用例来记录流。应在流中概述或映射所需的每个操作。捕获决策条件和路径。识别与其他用例的交互。此大纲用作流设计和管理的蓝图。还需要捕获有关流的业务信息。请确保在流文档中包含以下详细信息：

流说明：流的概要说明。
业务流程：流支持的业务流程。
流程所有者：拥有业务流程的个人。
利益干系人：应通知或咨询流状态或更改的个人。
升级路径：应联系的个人或组以解决问题。这是一个序列的人。个人责任的范围随着道路上的每个人而扩大。
业务影响：此流对业务的重要性。
严重性分级：指示流的相对重要性的定性标签。

有关详细信息，请参阅流示例。

定义流要求

利用用例建立流的技术目标。为流定义可衡量的目标，这些目标与 Well-Architected Framework (WAF) 的五大支柱保持一致。这些支柱提供了用于设置技术目标的框架：

可靠性目标：评估每个流的重要性并相应地设置可靠性目标。确定性能阈值并建立明确的服务级别协议， (SLA) 和目标 (SLO) 。关键性较高的流需要更严格的可靠性目标。
安全目标：根据数据敏感度和用户活动分析每个流的安全需求。实施并持续更新安全措施以满足这些需求，同时确保符合法规标准。
成本目标：了解每个流对有效资源分配的需求。设置目标以平衡成本和性能。确保资源使用情况与业务优先级保持一致。
操作目标：定义用于有效监视和故障排除的指标。目标应确保有效使用资源并与组织目标保持一致。
性能目标：基于每个流的初始要求确定性能目标。确保基本流获得足够的资源，并持续调整目标以满足不断变化的需求并增强用户体验。

设计流

设计流以满足技术目标。你应该熟悉流设计最佳做法，以便获得正确的结果。生成并测试流。循环访问设计，直到它满足你建立的技术目标。

遵循流设计最佳做法

设计流时，请遵循流设计最佳做法。设计良好的流具有以下属性：

作用域：确定每个流的不同起点和终点。清除边界有助于优化用户或系统交互。
逻辑： 使用步骤的逻辑顺序设计流。优化最有效的路径并减少不必要的步骤。
可维护：易于更新和维护的设计流。使用可在不影响整个工作负载的情况下进行修改的模块化组件。
定义：合并触发或指导流中每个步骤的特定条件。此精度可确保流准确响应用户输入、数据更改或系统状态。
可靠：将错误处理和异常路径生成到流中。有效的错误管理可防止中断，并在意外情况下保持流完整性。
可缩放：确保它可以处理不同的负载，并适应不断增长的或缩小的用户群或数据量。
安全：在流中嵌入安全措施。保护数据和用户交互免受未经授权的访问和威胁。
高效：在不过度预配的情况下规划资源的有效使用。请记住成本优化。
以用户为中心：对于用户流，流设计与用户期望和行为保持一致。使其直观，减少新用户的学习曲线。

开发和测试流

开发流以满足技术目标，并对其进行测试，以确保它满足其要求。此过程验证流是否按预期运行、高效处理其任务并满足技术目标。下面是生成和测试流的指南：

选择技术：选择在可靠性、安全性和性能方面与设定的目标一致的技术。
开发流：根据设计生成流，同时牢记设定的目标。
测试流：执行测试以确保流符合目标。根据需要进行迭代以满足目标。
监视：实施监视工具来跟踪资源使用情况和成本。

根据设定的目标和行业标准定期查看流。使用来自监视和审核的反馈来改进流。根据需要调整目标和流程，以适应不断变化的业务需求或技术进步。

优化流

在整个流的生命周期中重复本文中定义的过程。在循环访问流设计时，请使用 Well-Architected Framework 从每个支柱的角度优化流：

流示例

下面是一些流示例，可帮助你设计流。这些示例使用可靠的 Web 应用模式参考体系结构作为基础，并显示每个流上应提供的文档。

用户流 1：创建即将举行的音乐会

流程说明：呼叫中心员工使用应用程序创建即将举行的音乐会。

业务流程：此流程支持 购买票证 流程，但它是异步的，降低了其关键性。
流程所有者：销售总监。
利益干系人：销售部门、音乐会规划和运营、平台团队和应用程序团队。
升级路径：应用程序团队、平台团队，然后是销售部门。
业务影响：此流对于在销售平台上提供新音乐会非常重要，直接影响业务main收入流。当呼叫中心员工由于此流不可用而无法创建音乐会时，会对收入和公司的声誉产生负面影响。但是，高可用性对于此过程并不是必需的，因为音乐会通常每周提前安排一次。销售部门为此流程指定了 95% 的可用性要求，并且出于维护目的，同意在工作时间之外停机。
严重性分级：低。

用户流 2：搜索音乐会

流程说明：呼叫中心员工使用应用程序搜索即将举行的音乐会。

业务流程：此流程支持 购买票证 流程，但如果搜索功能不可用，呼叫中心员工可以选择列出所有音乐会。
进程所有者：用户体验 (UX) 部门。
利益干系人：销售部门、平台团队和应用程序团队。
升级路径：应用程序团队、平台团队、销售部门经理随叫随到。
业务影响：此流程允许呼叫中心员工快速查找音乐会，并且是正常销售流程的一部分。此流的高可用性并不重要，因为员工即使在没有音乐会的情况下也能列出音乐会。它确实会降低呼叫中心员工的体验，可能会降低并影响工作效率。客户可能会因等待时间增加或延迟而感到沮丧。销售部门要求在正常营业时间提供 99% 的此流。
严重性分级：中等。

用户流 3：获取音乐会列表

流程说明：呼叫中心员工使用应用程序获取音乐会列表。

业务流程：此流程直接支持 购买票证 流程。
进程所有者：平台总监。
利益干系人：销售部门、平台团队、数据团队。
升级路径：数据团队、数据团队待命工程师、平台团队待命工程师。
业务影响：此流是业务创收交易的关键路径不可或缺的一部分。高可用性至关重要，因为呼叫中心员工依赖于此流程来处理票证购买。鉴于其重要性，业务要求此流运行时间达到 99.9%，其中包括延长工作时间。
严重性分级：高。

用户流 4：购买票证

流程说明：呼叫中心员工使用应用程序 (身份验证和授权 过程) ， (代表 Relecloud 客户) 即将举行的音乐会流程列表购买即将举行的音乐会 的票证。

业务流程：此流是应用程序的核心功能和流。
流程所有者：销售总监。
利益干系人：销售部门和所有技术团队。
升级路径：应用程序团队待命工程师、平台团队待命工程师、数据团队待命工程师、首席运营官。
业务影响：此流的高可用性至关重要，因为它直接支持客户购买票证。此流的任何故障或不可用都可能会显著影响收入和公司的声誉。企业为此重要流程设定了严格的要求，即使在延长的工作时间，预计运行时间也达 99.9%。
严重性分级：高。

用户流 5：身份验证和授权

流说明：呼叫中心员工安全登录到应用程序。管理员为他们提供适当的角色来代表 Relecloud 客户购买票证。

业务流程：此流程直接支持 购买票证 流程。如果没有此功能，呼叫中心员工将无法登录到应用程序以购买票证。
进程所有者：平台团队。
利益干系人：平台团队、运营团队和销售部门。
升级路径：平台团队待命工程师、首席运营官。
业务影响：此流需要高可用性，因为如果此流无法正常工作，呼叫中心员工将无法购买票证。如果此流不可用，它将直接影响收入和信誉。这是一个关键过程，企业期望 99.9% 的运行时间，包括在延长的工作时间。
严重性分级：高。

系统流：收集遥测数据

流说明：为了了解生产系统中的状态更改，Web 应用程序和 API 实例收集并发送信息、错误和警告。此数据可帮助运营团队执行异常情况检测、故障排除和分析。

业务流程：此流不支持任何业务流程，但它为运营团队提供重要数据。
进程所有者：运营总监。
利益干系人：运营团队、平台团队和数据团队。
升级路径：运营团队 (24/7) ，数据团队的待命工程师。
业务影响：此流对于业务的监视和持续改进工作至关重要。它需要尽可能多余且可复原。运营团队负责在任何失败后快速还原此流，以避免丢失关键信息和警告。如果流无法实现预期的可用性，则存在忽略生产问题的风险，这可能会导致严重后果。为了缓解此风险，运营部门的目标是 99% 的运行时间（24/7）。他们必须至少提前 48 小时安排与维护相关的停机时间。
严重性分级：中等。

Share via