你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用流优化工作负荷设计
本文介绍使用流对工作负荷进行有针对性的优化。 工作负荷的不同组件具有不同的要求和重要性级别。 通过将工作负荷细分为流，可以确定工作负荷的不同部分的优先级，并更好地将工作负荷投资与每个流的重要性保持一致。
此工作负荷优化过程是迭代的，涉及三个关键步骤：（1）定义工作负荷中的流结构，（2）定义技术要求，（3）设计流以满足要求（见图 1）。
图 1：使用流优化工作负荷的过程。
定义流
在定义流要求之前，需要了解流的业务驱动因素。 定义流的先决条件是标识业务流程及其支持的用例。 了解先决条件后，可以开始记录流。
了解先决条件
流是支持工作负荷功能的操作序列。 有两种主要类型的流：用户流和系统流。 用户流确定用户交互。 系统流确定工作负荷组件之间的通信。 流支持业务流程和用例。 工作负荷由多个用例组成。 在记录流之前，需要确定流程支持的业务流程和用例（请参阅图 2）。
图 2：业务流程、用例、流和工作负荷之间的关系。
确定业务流程
业务流程是满足业务需求的一系列操作（阶段）。 流确定用户或数据完成业务流程的每个阶段所要执行的顺序。 例如，在线销售产品是一个业务流程。 此业务流程中的阶段可能是在线列出产品、接收订单和交付产品。
确定用例
用例定义流的功能要求。 在确定流的技术要求之前，需要确定和了解流支持的用例。 每个用例都应支持业务流程中的一个阶段（见图 2）。 用例应定义以下属性：
目的：明确阐明任务或目标，例如启用在线购买。 此清晰度指导功能设计，并为流设计设定明确的目标。
关键性：评估用例的重要性，范围从例程到关键。 分配给用例的值会告知流的优先级和设计。 高价值用例可能需要增强的错误处理、性能优化或用户体验注意事项。
使用者：确定用户（客户、员工）还是系统组件是主要使用者。 此分类确定是用户流还是系统流，并影响设计。
事件：定义启动和结束用例的触发器或条件。 这些事件定义流的边界。
执行：了解用例的操作频率和可变性，以预测系统负载。 必须设计流来处理不同的执行方案。
依赖项：识别与其他风险管理用例的相互依赖性。 识别用例的依赖项有助于设计与其他系统部件顺利集成的流。 你需要确保必要的输入和输出与后续进程的兼容性的可用性。
记录流
使用用例来记录流。 应在流中概述或映射所需的每个操作。 捕获决策条件和路径。 确定与其他用例的交互。 此大纲用作流程设计和管理的蓝图。 还需要捕获有关流的业务信息。 请确保在流文档中包含以下详细信息：
流说明：流的高级说明。
业务流程：流支持的业务流程。
进程所有者：拥有业务流程的个人。
利益干系人：应告知或咨询流状态或更改的人员。
升级路径：应联系的个人或组来解决问题。 这是一系列人。 个人责任的范围在路径上与每个人一起增长。
业务影响：此流对业务的重要性。
关键性分级：指示流的相对重要性的定性标签。
有关详细信息，请参阅 Flow 示例。
定义流要求
利用用例建立流的技术目标。 为符合良好架构框架（WAF）五大支柱的流定义可衡量的目标。 这些支柱提供了用于设置技术目标的框架：
可靠性目标：评估每个流的重要性并相应地设置可靠性目标。 确定性能阈值并建立明确的服务级别协议（SLA）和目标（SLO）。 较高的关键性流需要更严格的可靠性目标。
安全目标：根据数据敏感度和用户活动分析每个流的安全需求。 实施并持续更新安全措施以满足这些需求，同时确保符合法规标准。
成本目标：了解每个流对有效资源分配的需求。 设置目标以平衡成本与性能。 确保资源使用情况与业务优先级保持一致。
操作目标：定义用于有效监视和故障排除的指标。 目标应确保高效的资源使用和与组织目标保持一致。
性能目标：基于每个流的初始要求的基本性能目标。 确保基本流接收足够的资源，并持续调整目标以满足不断变化的需求并增强用户体验。
设计流
设计流以满足技术目标。 你应该熟悉流设计最佳做法，以便实现正确的结果。 生成并测试流。 循环访问设计，直到它满足你建立的技术目标。
遵循流设计最佳做法
在设计流时，请遵循流设计最佳做法。 设计良好的流具有以下属性：
作用域：确定每个流的不同的起始点和结束点。 清除边界有助于优化用户或系统交互。
逻辑： 使用逻辑步骤顺序设计流。 针对最有效的路径进行优化并减少不必要的步骤。
可维护：设计易于更新和维护的流。 使用模块化组件，无需影响整个工作负荷即可进行修改。
定义：合并触发或指导流中每个步骤的特定条件。 此精度可确保流准确响应用户输入、数据更改或系统状态。
可靠：在流中生成错误处理和异常路径。 有效的错误管理可防止中断，并在意外情况下维护流完整性。
可缩放：确保它可以处理不同的负载，并适应不断增长的或收缩用户群或数据卷。
安全：在流中嵌入安全措施。 保护数据和用户交互，防止未经授权的访问和威胁。
高效：在不过度预配的情况下规划资源的有效使用。 请记住成本优化。
以用户为中心的：对于用户流，将流设计与用户期望和行为保持一致。 使其直观，减少新用户的学习曲线。
开发和测试流
开发流以满足技术目标并对其进行测试，以确保它满足其要求。 此过程验证流是否按预期运行，有效地处理其任务，并满足技术目标。 下面是生成和测试流的指南：
选择技术：根据可靠性、安全性和性能选择与设定目标相符的技术。
开发流：根据设计生成流，牢记设定的目标。
测试流：执行测试以确保流满足目标。 根据需要循环访问以满足目标。
监视：实现监视工具来跟踪资源使用情况和成本。
根据设定的目标和行业标准定期审查流。 使用来自监视和审核的反馈来改进流。 根据需要调整目标和流程，以符合不断变化的业务需求或技术进步。
优化流
在流整个生命周期内重复本文中定义的过程。 在循环访问流设计时，请使用精心构建的框架从每个支柱的角度优化流：
流示例
下面是一些流示例，可帮助你设计流。 这些示例使用 可靠的 Web 应用模式参考体系结构 作为基础，并显示每个流上应具有的文档。
用户流 1：创建即将推出的音乐会
流程说明：呼叫中心员工使用应用程序创建即将到来的音乐会。
业务流程：此流支持 购买票证 流程，但它是异步的，降低了其关键性。
流程所有者：Sales 主管。
利益干系人：销售部门、音乐会规划和运营、平台团队和应用程序团队。
升级路径：应用程序团队、平台团队，然后是销售部门。
业务影响：此流对于在销售平台上推出新音乐会非常重要，直接影响业务的主要收入流。 当呼叫中心员工由于此流不可用而无法创建音乐会时，它将对收入和公司的声誉产生负面影响。 但是，高可用性对于此过程并不重要，因为音乐会通常每周提前安排一次。 销售部门为此流程指定了 95% 的可用性要求，并同意在工作时间之外停机，以便进行维护。
严重性分级：低。
用户流 2：搜索音乐会
流程说明：呼叫中心员工使用应用程序搜索即将举行的音乐会。
业务流程：此流程支持 购买票证 流程，但如果搜索功能不可用，呼叫中心员工可以选择列出所有音乐会。
进程所有者：用户体验（UX）部门。
利益干系人：销售部门、平台团队和应用程序团队。
升级路径：应用程序团队、平台团队、销售部门经理待命。
业务影响：此流程允许呼叫中心员工快速查找音乐会，并且是正常销售过程的一部分。 此流的高可用性并不重要，因为员工即使在缺少音乐会的情况下也能列出音乐会。 它确实会降低呼叫中心员工的体验可能会降低并影响工作效率。 由于等待时间或延迟增加，客户可能会感到沮丧。 销售部门要求在常规工作时间提供此流的 99%。
严重性分级：中等。
用户流 3：获取音乐会列表
流程说明：呼叫中心员工使用应用程序获取音乐会列表。
业务流程：此流程直接支持 购买票证 流程。
进程所有者：平台主管。
利益干系人：销售部门、平台团队、数据团队。
升级路径：数据团队、数据团队呼叫工程师、平台团队待命工程师。
业务影响：此流是业务收入生成交易的关键路径不可或缺的一部分。 高可用性至关重要，因为呼叫中心员工依靠此流程来处理票证购买。 为了认识到其重要性，业务为此流规定 99.9% 的运行时间，其中包括延长的工作时间。
关键性评级：高。
用户流 4：购买票证
流程说明：呼叫中心员工使用应用程序（ 身份验证和授权 过程）代表 Relecloud 客户购买即将举行的音乐会（ 列表即将举行的音乐会 流程）的票证。
业务流程：此流是应用程序的核心功能和流。
流程所有者：Sales 主管。
利益干系人：销售部门和所有技术团队。
升级路径：应用程序团队呼叫工程师、平台团队呼叫工程师、数据团队呼叫工程师、首席运营官。
业务影响：此流的高可用性至关重要，因为它直接支持客户票证购买。 此流的任何故障或不可用都可能会影响收入和公司的声誉。 该业务为这一重要流程设定了严格的要求，预计运行时间为 99.9%，即使在延长的工作时间也是如此。
关键性评级：高。
用户流 5：身份验证和授权
流程说明：呼叫中心员工安全地登录到应用程序。 管理员为他们提供适当的角色，代表 Relecloud 客户购买票证。
业务流程：此流程直接支持 购买票证 流程。 如果没有此功能，呼叫中心员工无法登录到应用程序购买票证。
进程所有者：平台团队。
利益干系人：平台团队、运营团队和销售部门。
升级路径：平台团队待命工程师、首席运营官。
业务影响：此流需要高可用性，因为如果此流无法正常工作，呼叫中心员工无法购买票证。 如果此流不可用，则直接影响收入和信誉。 这是业务需要 99.9% 运行时间的关键过程，包括延长工作时间。
关键性评级：高。
系统流：收集遥测
流说明：为了了解生产系统中的状态更改，Web 应用程序和 API 实例收集并发送信息、错误和警告。 此数据可帮助运营团队执行异常情况检测、故障排除和分析。
业务流程：此流不支持任何业务流程，但它为运营团队提供了重要数据。
进程所有者：Operations 主管。
利益干系人：运营团队、平台团队和数据团队。
升级路径：运营团队（24/7），数据团队待命工程师。
业务影响：此流对于企业的监视和持续改进工作至关重要。 它需要尽可能冗余和复原。 运营团队负责在发生任何故障后快速还原此流，以避免缺少关键信息和警告。 如果流无法实现预期可用性，则存在忽略生产问题的风险，这可能会导致严重后果。 为了缓解此风险，运营部门的目标是 99% 的运行时间，即 24/7。 他们必须提前至少 48 小时计划与维护相关的停机时间。
严重性分级：中等。