你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
标识和分级流的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：02 | 识别和评价用户和系统流。 根据业务需求使用关键性缩放来确定流的优先级。 |
|---|
本指南介绍用于识别和确定工作负荷流的优先级的建议。 识别和确定工作负荷流的优先级涉及将用户流和系统流映射到组织。 这种做法可确保识别并确定最重要的工作负荷功能优先级，以减少损坏故障的风险。 无法识别和确定工作负荷流的优先级可能会导致系统故障和工作负荷可靠性受损。
定义
| 术语 | 定义 |
|---|---|
| 用户流 | 用户在应用程序或系统中执行的操作的路径或序列。 |
| 系统流 | 系统中的信息和进程的流。 系统会自动遵循此流来启用用户流或工作负荷功能。 |
关键设计策略
设计工作负荷时，必须定义用户流和系统流。 用户流绘制用户通过应用程序移动的图表。 他们专注于用户界面、交互、决策和完成任务所需的步骤。 用户流提供以用户为中心的用户体验和界面设计视角。 系统流绘制工作负荷的内部工作图表。 它们侧重于工作负荷组件、后端服务和外部 API 之间的数据移动、输入处理、输出处理和交互。 系统流指示工作负荷在内部运行方式的复杂细节。
应在工作负荷的设计阶段早期识别和定义流。 它让你更清楚地了解影响工作负荷可靠性的内容。 它与工作负荷的可靠性目标紧密匹配体系结构决策。
标识所有用户和系统流
识别所有用户和系统流的输出是工作负载中所有流的目录。 此识别过程要求从头到尾映射系统中的每个用户交互和过程。 此映射是识别关键流的先决条件。 下面是用于识别工作负荷中所有用户和系统流的建议：
采访利益干系人。 利益干系人可以提供有价值的信息来识别流，他们甚至可以帮助你映射和确定流的优先级。 还可以采访用户、业务分析师和技术团队，以收集有关工作负荷中用户交互和依赖项的见解。
查看文档。 在设计阶段，你可能没有文档需要查看。 但是，如果存在文档，则应使用它。 请求系统体系结构关系图、用户手册和流程说明。 这些文档可帮助你了解工作负荷及其各个流的预期功能。
观察工作负荷。 监视操作中的工作负荷，指出用户如何与其交互，以及不同组件彼此之间的相互通信方式。 应分析系统日志、性能指标和用户活动日志，以确定模式、频繁的任务和系统响应。
列出标识的流。 面试、文档和观察应使你能够识别工作负荷中的所有流。 编译标识的所有流的列表，并将其分类为用户流（专注于用户交互）和系统流（侧重于后端进程和数据移动）。
定义流起点和终点。 对于每个已识别的流，请明确定义流开始的位置及其结束位置。 对于用户流，请记录每个用户交互及其预期结果。 专注于用户体验和界面设计。 对于系统流，需要确定其基础触发器和预期结果。
分解每个流。 将每个流分解为各个步骤，描述每个点发生的操作、决策或进程。 请注意每个步骤如何与系统的其他部分交互，包括对其他流或外部系统的依赖关系。 应该能够确定流如何与工作负载和用户体验集成并影响。 这种双重方法提供了整个工作负荷的整体视图。
文档唯一输出。 确定每个流中的任何替代路径或异常，例如错误处理或条件分支。 如果流具有多个可能的结果，则应将其作为不同的条目添加到目录中。 对于用户流，应确定交互的预期行为。 对于系统流，应标识进程的预期行为。
使用关系图可视化。 创建流程图或关系图以直观地表示流及其步骤。 可以使用Microsoft Visio、UML 序列图、用例图、简单绘图工具或文本格式的描述性列表等工具（请参阅示例流目录）。
以迭代方式更新流映射。 流映射是一个迭代过程。 流可以更改、拆分或合并，尤其是在设计阶段。 随着工作负荷流的定义更加明确，应更新流的目录以匹配。 使用利益干系人提供的反馈验证和优化流程图，以确保准确性和完整性。
确定每个流的业务流程
业务过程是实现输出的一系列任务，例如订单履行、客户服务管理或库存控制。 每个流的业务过程标识涉及将流映射到一个或多个业务过程。 此映射有助于了解每个流对业务的重要性。
你可能有现有的文档或业务计划，这些文档或业务计划提供流到业务流程的映射。 有时，用户手册、培训材料或系统规范可以提供对工作负荷及其流的预期用途和用途的见解。 如果没有，则需要将流映射到它们支持的业务流程。 下面是用于确定每个流的业务流程的建议：
使用工作负荷输出。 可以使用工作负荷输出和流细分将流与它们支持的业务流程相关联。 首先，查看工作负荷生成的输出。 输出可以是销售报表、数据文件或已完成的任务。
进行面试。 与与工作负荷交互的团队成员和利益干系人交谈。 应询问有关其日常任务的具体问题、如何使用工作负荷以及它们实现的目标。 技术团队通常更深入地了解工作负荷结构，并可以深入了解其支持的业务流程。
监视工作负荷使用情况。 对于现有工作负荷，请监视工作负荷，并查找使用情况中的模式，这些模式指示基础业务流程，例如数据输入、订单处理或客户交互。
将输出连接到业务流程。 将流输出中的点连接到它们支持的整体业务流程。 例如，如果流步骤涉及处理客户订单，则它直接支持订单履行的业务流程。 订单履行有助于保持客户满意度和创造收入的业务目标。 最后，使用流明细来帮助确定哪个流创建了销售报表。
确定每个流的流程所有者和利益干系人
流的过程所有者是负责成功执行给定过程的人。 他们负责该过程和支持该过程的流。 应确定每个工作负责流的过程所有者。 还应确定每个流的利益干系人。 利益干系人可以参与工作负荷、依赖于流或管理流具有的依赖项。
你可能有一个责任分配矩阵（RAM）或 RACI 矩阵，该矩阵已经标识了进程所有者和利益干系人。 通常，过程所有者对流程负责或有责任，而利益干系人是你的咨询或通知对象。
确定每个流的升级路径
升级路径的识别是指确定与流相关的问题的升级渠道。 需要升级的问题可能是紧急更新、安全问题、降级或技术事件。 确定上报路径的目标是确保问题及时有效地得到解决。
映射的升级路径应从最有可能解决特定问题的个人或组开始。 如果此人或组无法解决问题，升级路径应确定下一个联系人点。 下一个接触点具有更广泛的职责，能够与组织更多部分协调缓解策略。 升级路径上的人数因流和组织而异。 升级路径上的太多人可能会减缓解决工作的速度。
确定每个流的业务影响
确定每个流的业务影响对于了解每个流对关键业务目标的贡献至关重要。 业务影响可能包括创收、客户满意度或运营效率。 通过了解每个流的正面和负面影响，可以确定工作优先级，以确保对业务而言最重要的流的可靠性。 请务必考虑流故障的直接影响及其对其他互连进程的间接影响。 下面是确定每个流的业务影响的步骤：
确定积极影响。 确定流按预期运行时的预期优势。 预期的好处可能包括提高效率、增加收入、提高客户满意度，或对业务产生任何其他积极影响。
确定负面影响。 评估进程失败或无法按预期工作的潜在负面影响。 考虑量化特定损失，例如收入下降。 包括损害信誉、客户信任侵蚀或对其他相关业务流程的不利影响等主观影响。
定义容量和可用性假设。 确定有关每个流程的预期容量和可用性的假设。 考虑以下因素：每个单位时间的吞吐量、预期的工作时间和目标百分比运行时间。 如果对恢复时间目标（RTO）或恢复点目标（RPO）有预期，则应包括这些期望。 这些假设有助于了解每个流的可靠性要求。
通过系统地评估这些方面，你可以全面了解每个流对业务的影响，并就可靠性优化做出战略决策。
为每个流分配关键性分级
通过对流相对于整体业务影响的重要性进行详细评估，可以为每个流分配关键性评级。 可以使用定量或定性关键性评级。 目的是按优先级对流进行排序，并分配一个标签，用于标识关键流。 此过程是识别、映射和与业务流程和影响保持一致的逻辑延续。 使用以下关键性说明来分配关键分级：
高关键性：高关键性流是核心业务功能不可或缺的一部分。 它们直接影响到业务的关键方面，例如客户体验、财务交易、安全协议、人类健康和安全。 这些流的失败或中断可能导致严重的直接或长期负面影响。 负面影响的示例包括收入损失、违反信任和法律问题。 优先处理这些流可确保工作负荷最关键的方面是可靠且可复原的。
中等关键性：中等关键性流对于系统的完整功能非常重要，但不直接与客户或关键业务运营进行交互。 例如，如果问题中断了内部数据处理流，则可以重试数据处理，而不会立即产生外部影响。 这些流对于顺利运营至关重要，但在即时客户或财务效果方面提供了缓冲，从而允许对问题的托管响应。
低关键性：低关键性流对核心业务功能或客户体验没有直接影响或显著影响。 示例包括诸如夜间日志传输或可选用户功能（如反馈调查）等辅助过程。 虽然这些流有助于整个系统，但他们的中断不太可能导致严重的直接业务或运营问题。
通过遵循此结构化方法来分配关键性，可以有效地确定资源优先级，并专注于维护和提高最关键流的可靠性和有效性。
权衡：可靠性预期较高有时与操作员设置成本、运营成本和管理负担较高相吻合。 确保利益干系人了解提高关键流可靠性的潜在成本增加。
组织遵循情况
云采用框架为需要业务关键性分类的工作负荷提供指导。
有关详细信息，请参阅 云管理中的业务关键性。