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