这是 Zendesk 事务管理概览的第 2 部分。本指南包含以下部分：
- 第 1 部分：Zendesk 服务问题如何变为服务事务
- 第 2 部分：Zendesk 如何管理服务事务（本文）
- 第 3 部分：监测公开 Zendesk 服务事务
- 第 4 部分：解决后事务分析和报告
在本文章第 2 部分中，您将了解 h现在的 Zendesk 团队会根据严重级别对产品中的服务事务做出响应。Zendesk 采用全面的方法来了解事务 —— 从其根本原因到对受影响客户的总体影响 —— 并传达适当的详细信息。
本文章包含以下组别：
事务严重性
创建服务事务时要做的关键决策之一是分配事务的严重性。事务的严重性决定了 Zendesk 团队解决问题的方式和范围，以及如何将问题传达给受影响的客户。
Zendesk 系统根据事务特征将服务事务分为 5 个严重级别：
Zendesk 严重性评价系统
不同的升级路径和团队将根据事件的严重性级别，进行调查、沟通和修复。这可确保每个事务得到适当严格的处理。下图根据其严重级别描述了清除事务期间和之后发生的关键活动：
按严重级别处理
高严重性事件会经历严格的分析和修复活动，而每个事件 - 无论严重性级别如何 - 都会经历实时响应和调查流程。这将产生：
- 事务 公开时的Zendesk 状态页面更新
- 根本原因分析和事务修复
- Zendesk（内部）事务报告
Zendesk 服务空闲状态事务示例
以下示例说明了 Zendesk 如何设置事务严重性，以及 Zendesk 团队如何进行内部响应：
事务发现和响应示例
本例中有以下工作流程：
- Zendesk 网络运营中心 (ZNOC) 识别出一个问题 当系统警报显示请求无法到达 Pod 17 中的服务节点时。Zendesk 网络工程团队核实了访问问题是否直接影响到客户服务，并很快意识到多个客户的 Support、Guide 和 Talk 服务无法如期运行。已创建新的 Zendesk 服务事件。
- 已知此事务在最初创建时会影响两个客户，但由于中断的性质，更多的客户遇到此问题，并开始向 Zendesk 客户支持报告问题。工程团队将此事务评为 1 级——高优先级事务，需要立即关注。
- 待命团队立即收到了传呼。事务创建后几分钟内，事务经理就收集了信息并集合了更多工程资源以排除故障并修复了此服务事务。
事务响应团队结构
Zendesk 有一个专门的全球事务响应团队，以确保每个事务都通过服务事务管理流程进行引导，并在必要时上报给适当级别的 Zendesk 领导层。
事务管理用户角色和职责
这种团队结构使 Zendesk 能够运用技术资源对事务进行全面分析，并通过 Zendesk 客户支持与客户实时沟通。
事务通讯时间线
Zendesk 致力于确保就客户而言，事务得到妥善沟通并在适当时间范围内得到解决。我们已制定事务详情分发的内部时间表。时间线基于事务的严重性级别和服务事务管理阶段。
|
阶段 |
响应时间线 |
|
公告 |
在拨打电话事件发生后 15 分钟内 |
|
事务更新 |
每 30 分钟一次，直到服务恢复或有新信息可用 |
|
事件分析 （对于严重性为 0 和 1 级事务） |
事务解决后 48 小时内 |
|
根本原因分析 |
事务解决后 72 小时内 |
|
公开事件回顾 |
事务解决后 96 多小时内 |
严重性等级为 0 - 2 的事务被视为“ 高” 严重程度的事务。发生高严重性事务时，全球事务响应团队将全天候待命，以便对这些事务做出响应。该团队由以下用户角色组成：
事务响应团队用户角色
事件响应团队全球位置
当待命团队接到寻呼时，事件诊断会在事件被宣布后几分钟内开始。创建 Slack 频道和 Zoom 通话以实现响应团队的实时通讯。当事务响应团队对事务进行分类并确定范围时，将根据受影响的产品和服务寻呼待命的工程团队。
Zendesk 状态页面上的公开帖子 会在事务创建后 15 分钟内进行，以便让客户了解已知事务。此后每 30 分钟发布一次更新，直到有新的信息可解决为止。根据问题以及识别出的新信息量，此周期可适当放慢或延长。 客户可在 Zendesk 状态页面上监测活跃的服务事务 —— 该流程参见 本指南的第 3 部分。
除了我们待命的全球事务响应团队之外，Zendesk 还建立了通知领导层和升级的流程。如果高严重性事件符合特定标准，我们将启用下一级响应，即危机管理。
Zendesk 服务空闲状态事务范例（续）
以下继续以服务可用性事务 为例，说明事务响应通过 Zendesk 事务管理流程的进展情况：
服务可用性事务响应时间线
如本例所示，在 Zendesk 事务门户中创建事务后，系统会执行一系列自动操作：
- 已呼叫事件响应随叫随到的团队以响应事件
- 事务响应 on-call 团队已添加到专用 Slack 渠道
- Zoom 通话已自动开始，并发布到 Slack 频道，供所有应答者加入
- 系统会自动创建“活动概要文档”以记录该事务，并在 Zendesk 内部共享进度
在 Zoom 通话中，事务经理验证了问题的初始严重性，并确认了问题的范围和影响。
很快确定 Pod 17 中有多个容器节点无法访问，相关服务无法使用包括 Support、Guide 和 Talk 产品在内的相关服务。一个节点类型在其他 pod 中没有可用副本。这最终将导致这些产品对多个客户失去响应。
为此，ZNOC 已呼叫相关网络工程团队加入 Zoom 电话会议，以开始研究如何解决恢复客户服务和 API 访问权限等紧迫问题。 边缘工程中小企业也收到了呼叫转移，并加入了通话。在 5 分钟内，我们就识别并部署了修复程序，使受影响的节点再次可以访问 API 调用和服务。
Zendesk 客户支持创建了一张故障工单来跟踪客户报告。此工单已添加到事务 Slack 渠道，以便在有新报告时快速添加。
在调查继续期间，事务升级管理者在事务创建 12 分钟后，创建并发布了 Zendesk 状态页面的首次公开更新。
Zendesk 系统状态页面上发布的首次服务可用性事务
在团队调查此事务的同时，将收到的客户报告链接到与此事务相关的主要故障工单。这样事件响应团队就可以在所有受影响的客户发出公开通知时向他们发送更新。
网络工程团队确定这起事件与证书的生成和使用方式更改有关，并采取了以下措施来恢复对受影响客户的服务：
- 已取消激活的不可达节点
- 已使用正确引用的证书创建新的服务节点
- 已验证新服务节点可供服务并通过 API 调用进行访问
- 监测入站流量，查看入站请求现在是否得到了适当处理
随着事件的发展，又有两项公开更新发布：两次分别在创建事务后 14 分钟和 63 分钟后提交。公开通讯历史记录以及已发布的事务可追溯信息位于“ 服务通知”页面 ，用于事务。
如本例所示，高严重性事务需要经过一个严格的流程，以确定根本原因，并为产品工程团队创建修复项目，以解决导致事务的根本问题。此分析在我们的事务回顾期间进行，详见 “解决后事务分析”部分。
低严重性事务流程
严重程度较低的服务事件（级别 3-4）则不太重要，因为它们影响的客户数量较少，并且不会阻止这些客户使用 Zendesk 产品的关键业务功能。这些事务将根据上述指南得到解决，但不会发布到公开渠道。
严重性为 3 的事务的处理方式与严重性为 0-2 的事务大致相同。由于业务影响降低，预期响应时间有所延长。即使待命团队没有得到寻呼，这些事务也会通过与支持产品工程团队关联的特定 Zendesk 事务 Slack 渠道进行处理，且这些团队往往会与较高严重性事务一样快速响应。大多数严重性为 3 的事务不使用公开沟通渠道。相反，如果需要一部分客户进行特定操作，Zendesk 客户支持团队会通过主动通知联系客户。
严重程度为 4 的事务不会直接影响客户对 Zendesk 服务的使用，但如果不加以解决则可能产生影响。创建这些事务是为了主动响应潜在的问题。产品工程团队的互动方式与严重性 3 流程相同。
了解更多
以上就是 Zendesk 事务管理 概览中第 2 部分“Zendesk 如何管理服务事务”的部分。
如果您想了解更多，可以阅读本指南的下一部分： 第 3 部分：监测公开 Zendesk 服务事务更新。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。