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

有关识别流和分级流的建议

适用于此 Azure Well-Architected 框架可靠性清单建议：

RE：02	识别和评价用户和系统流。 根据业务需求使用关键性缩放来确定流的优先级。

本指南介绍有关识别工作负荷流和确定工作负荷流的优先级的建议。 确定工作负载流并确定其优先级涉及映射用户流和系统流，以确定它们对组织的关键性。 这种做法可确保确定最关键的工作负载功能并确定其优先级，以降低损坏故障的风险。 未能确定工作负载流并确定其优先级可能会导致系统故障和工作负载可靠性受损。

定义

术语	定义
用户流	用户在应用程序或系统中执行的操作的路径或序列。
系统流	系统中的信息和进程的流。 系统会自动遵循此流来启用用户流或工作负载功能。

关键设计策略

设计工作负载时，必须定义用户流和系统流。 用户流绘制用户通过应用程序移动的图表。 他们专注于用户界面、交互、决策以及完成任务所需的步骤。 用户流在用户体验和界面设计方面提供以用户为中心的视角。 系统流绘制工作负载的内部工作图。 它们侧重于工作负载组件、后端服务和外部 API 之间的数据移动、输入处理、输出处理和交互。 系统流指示工作负载在内部运行的复杂细节。

应在工作负载设计阶段的早期识别和定义流。 它使你能够更清楚地了解影响工作负荷可靠性的因素。 它使体系结构决策与工作负载的可靠性目标紧密相连。

识别所有用户和系统流

标识所有用户和系统流的输出是工作负载中所有流的目录。 此标识过程要求你从头到尾映射系统中的每个用户交互和进程。 此映射是识别关键流的先决条件。 下面是用于识别工作负载中所有用户和系统流的建议：

• 采访利益干系人。 利益干系人可以提供有价值的信息来识别流，他们甚至可以帮助你映射和确定流的优先级。 还可以采访用户、业务分析师和技术团队，以收集有关工作负载中用户交互和依赖项的见解。

• 查看文档。 在设计阶段，可能没有文档可查看。 但是，如果文档存在，则应使用它。 询问系统体系结构关系图、用户手册和过程说明。 这些文档可帮助你了解工作负荷及其各个流的预期功能。

• 观察工作负荷。 监视运行中的工作负载，并注意到用户与其交互的方式以及不同组件之间的相互对话方式。 应分析系统日志、性能指标和用户活动日志，以识别模式、频繁任务和系统响应。

• 列出标识的流。 面试、文档和观察应使你能够识别工作负载中的所有流。 编译标识的所有流的列表，并将其分类为用户流， (侧重于用户交互) 和系统流 (侧重于后端进程和数据移动) 。

• 定义流的起点和终点。 对于每个已标识的流，请明确定义流开始的位置和结束位置。 对于用户流，请记录每个用户交互及其预期结果。 专注于用户体验和界面设计。 对于系统流，需要确定其基础触发器和预期结果。

• 分解每个流。 将每个流分解为单独的步骤，描述每个点发生的操作、决策或进程。 请注意每个步骤如何与系统的其他部分交互，包括对其他流或外部系统的依赖关系。 应能够确定流如何与工作负载和用户体验集成并影响。 这种双重方法提供了整个工作负载的整体视图。

• 文档唯一输出。 确定每个流中的任何替代路径或异常，例如错误处理或条件分支。 如果流具有多个可能的结果，则应将其作为不同的条目添加到目录中。 对于用户流，应确定交互的预期行为。 对于系统流，应确定进程的预期行为。

• 使用关系图可视化。 创建流程图或图表以直观方式表示流及其步骤。 可以使用 Microsoft Visio、UML 序列图、用例图、简单绘图工具或文本格式的描述性列表等工具， (请参阅 示例流目录) 。

• 以迭代方式更新流映射。 流映射是一个迭代过程。 流可以更改、拆分或合并，尤其是在设计阶段。 随着工作负载流的定义更加明确，应更新流目录以匹配。 使用利益干系人的反馈验证和优化流程图，以确保准确性和完整性。

确定每个流的业务流程

业务流程是实现输出的一系列任务，例如订单履行、客户服务管理或库存控制。 确定每个流的业务流程涉及将流映射到一个或多个业务流程。 此映射可帮助你了解每个流对业务的重要性。

你可能拥有提供流到业务流程映射的现有文档或业务计划。 有时，用户手册、培训材料或系统规范可以提供有关工作负荷及其流的预期用途和用途的见解。 如果没有，则需要将流映射到它们支持的业务流程。 下面是确定每个流的业务流程的建议：

• 使用工作负载输出。 可以使用工作负载输出和流细分将流与其支持的业务流程相关联。 首先，查看工作负荷生成的输出。 输出可以是销售报表、数据文件或已完成的任务。

• 进行面试。 与与工作负载交互的团队成员和利益干系人交谈。 你应该询问有关其日常任务、他们如何使用工作负载以及他们通过工作负载实现的目标的具体问题。 技术团队通常对工作负载结构有更深入的了解，并可以提供有关其支持的业务流程的见解。

• 监视工作负荷使用情况。 对于现有工作负载，请监视工作负荷，并在使用中查找指示基础业务流程的模式，例如数据输入、订单处理或客户交互。

• 将输出连接到业务流程。 将流输出中的点连接到它们支持的整体业务流程。 例如，如果流步骤涉及处理客户订单，则它直接支持订单履行的业务流程。 订单履行有助于实现保持客户满意度和创造收入的业务目标。 最后，使用流明细来帮助确定哪个流创建了销售报表。

确定每个流的流程所有者和利益干系人

流的进程所有者是负责成功执行给定进程的个人。 他们负责该过程和支持该过程的流。 应确定每个工作负荷流的进程所有者。 还应确定每个流的利益干系人。 利益干系人可以参与工作负荷，对流具有依赖项，或管理流具有的依赖项。

你可能有一个责任分配矩阵 (RAM) 或 RACI 矩阵，该矩阵已经标识了进程所有者和利益干系人。 通常，流程所有者对某个流程负责或负责，你向利益干系人咨询或通知利益干系人。

确定每个流的升级路径

升级路径的标识是确定与流相关的上报问题的通道。 需要升级的问题可能是紧急更新、安全问题、降级或技术事件。 确定升级路径的目标是确保及时有效地解决问题。

规划的升级路径应从最有可能解决特定问题的个人或组开始。 如果此人员或组无法解决问题，则升级路径应标识下一个联系人。 下一个联系点承担更广泛的责任，能够与组织更多部门协调缓解策略。 升级路径上的人数因流程和组织而异。 上报路径上的太多人可能会减慢解决速度。

确定每个流的业务影响

确定每个流的业务影响对于了解每个流对关键业务目标的贡献至关重要。 业务影响可能包括创收、客户满意度或运营效率。 通过了解每个流的正面和负面影响，你可以确定工作优先级，以确保对业务最重要的流的可靠性。 请务必考虑流故障的直接影响及其对其他互连进程的间接影响。 下面是确定每个流的业务影响的步骤：

• 确定积极影响。 确定按预期方式运行流时的预期优势。 预期的好处可能包括提高效率、增加收入、提高客户满意度或对业务的任何其他积极影响。

• 确定负面影响。 评估进程失败或无法按预期工作的潜在负面影响。 请考虑量化特定的损失，例如收入下降。 包括主观影响，如声誉受损、客户信任受损或对其他相关业务流程的不利影响。

• 定义容量和可用性假设。 建立有关每个进程的预期容量和可用性的假设。 请考虑每个单位时间的吞吐量、预期工作时间和目标运行时间百分比等因素。 如果对恢复时间目标 (RTO) 或恢复点目标 (RPO) 的预期，则应包括这些预期。 这些假设有助于了解每个流的可靠性要求。

通过系统地评估这些方面，可以全面了解每个流如何影响业务，并就可靠性优化做出战略决策。

为每个流分配严重性分级

通过对流重要性（相对于整体业务影响）的详细评估，可以为每个流分配关键性分级。 可以使用定量或定性严重性分级。 目的是按优先级对流进行排序，并分配一个标签，用于识别关键流。 此过程是识别、映射和与业务流程和影响保持一致的逻辑延续。 使用以下严重性说明来分配关键级别：

• 高关键性：高关键性流是核心业务功能不可或缺的一部分。 它们直接影响业务的关键方面，例如客户体验、财务交易、安全协议、人类健康和安全。 这些流的失败或中断可能导致严重的直接或长期负面影响。 负面影响的示例包括收入损失、违反信任和法律问题。 确定这些流的优先级可确保工作负荷的最关键方面是可靠且可复原的。

• 中等关键性：中等临界度流对于系统的完整功能非常重要，但不会与客户或关键业务运营直接交互。 例如，如果问题中断了内部数据处理流，则可以重试数据处理，而不会立即产生外部影响。 这些流对于顺利运营至关重要，但在即时客户或财务效果方面提供了缓冲，允许对问题进行托管响应。

• 低关键性：低关键性流不会对核心业务功能或客户体验产生直接或重大影响。 示例包括辅助过程（如夜间日志传输）或可选用户功能（如反馈调查）。 虽然这些流有助于整个系统，但它们的中断不太可能导致重大的直接业务或运营问题。

通过遵循这种结构化方法来分配关键性，可以有效地确定资源的优先级，并专注于维护和提高最关键流的可靠性和有效性。

权衡：对可靠性的更高期望有时与操作员的设置成本、运营成本和管理负担较高相吻合。 确保利益干系人了解提高关键流可靠性的潜在成本增加。

组织遵循情况

云采用框架为需要业务关键性分类的工作负载提供指导。

有关详细信息，请参阅 云管理中的业务关键性。