客户事件管理策略

了解 Cloudflare 如何处理影响其生产环境的事件以及 Cloudflare 将这些事件的性质和影响传达给 Enterprise 客户的方式。

​​ 目的

Cloudflare 认为，开放性和透明性是我们提供服务所固有的，并致力于让我们的客户和整个 Internet 社区对我们树立信任。  Cloudflare 运营着一个全球网络，该网络影响着全球数亿人口的生活和繁荣，因此，我们非常注意这一责任。

本标准操作程序 (SOP) 定义了 Cloudflare 如何处理影响其生产环境的所有事件和问题，以及 Cloudflare 如何将这些事件的性质和影响传达给计划内和计划外的 Enterprise 客户，无论其严重性如何。 本程序指定了如何一致地开展这些工作，以便

• 最大限度地加长环境正常运行时间，
• 最大限度地减少对客户的影响，
• 减少维修时间，以及
• 与我们的客户和 Internet 社区共享信息。

​​ 范围

此 SOP 适用于 Cloudflare 客户和客户使用的客户服务。SOP 适用于 Cloudflare 的所有客户生产环境，包括：

• Cloudflare 的公共网站 ( www.cloudflare.com Open external link )
• Cloudflare 的 API（应用程序编程接口）
• 站外第三方接口（例如信用卡授权等）
• Cloudflare 拥有或管理的用于生产服务的网络基础架构
• 影响 Cloudflare 生产的任何部分的供应商软件、硬件和服务

​​ 背景

Cloudflare 的宗旨是构建更好的互联网。为了向数百万互联网用户提供更好的体验，Cloudflare 的内部运营必须遵循出色的服务交付流程和程序。 因此，Cloudflare 的程序遵循许多行业标准的最佳做法，其中一些遵循信息库基础结构技术 (ITIL) 的模式。 该 SOP 遵循 ITIL 问题管理方法的最佳做法。

​​ 定义

关键事件术语的类别： 所有事件都是可以引发警报的条件；有些警报是值得注意的事件（有些不是）；必须对所有事件进行分类（有时是通过自动化，有时是通过人机交互）；有些事件是问题；问题中有一些是“重大”问题，并且会激发状态页更新；一些重大事件具有较高的优先级 (P1)，这需要创建事件报告。

关键术语：

​​ 角色和责任

​​ 以下角色和责任与 Cloudflare 中的事件管理相关联：

​​ 标准操作程序

本节详细介绍事件和问题管理的过程。 从高层次上讲，这些过程涉及以下方面：

• 事件管理 观察和响应警报的整个过程，包括：评估事件的潜在影响和严重性；将事件分类为问题；为问题分配优先级；或在无法识别问题情况时将事件视为非影响事件 。

• 问题管理： 确定问题范围和程度、分配适当的严重性级别（P0、P1、P2、P3）、解决问题并恢复生产服务的最佳状态的措施，以及将问题传达给有关方面的过程。

• 解决方案管理： 调查导致问题状况的原因和条件、报告管理和解决问题的总体方式，以及今后如何防止导致问题的状况和原因的任何后续分析的过程。

​​ 事件管理

事件管理的主要目标是尽快识别潜在问题并做出反应，从而最大程度地减少对生产服务的影响，并提供尽可能最佳的服务质量和可用性。 服务质量和可用性的最佳可能水平是，所有服务在 100% 的时间内完全按照设计方式运行，并且在 100% 的时间内可用且可访问。

因为我们承认，我们控制范围内的力量和超出我们控制范围的力量的组合将最终影响服务质量，因此我们定义了服务级别目标 (SLO) 和服务级别协议 (SLA)，以描述对于 Cloudflare 网络中的各种服务，服务质量下降的可接受程度。  SLA 和 SLO 表示为一段时间（每月和每年）的百分比。

有关事件的信息级别可能会有所不同，但是在对事件进行分类和划分优先级之前，必须收集以下信息：

• 提交来源（监测警报或备用源）
• 客户（如适用）
• 系统或应用程序（和主机名，如适用）
• 警报时间
• 影响范围：受影响的系统、用户或区域的估计数量
• 影响类型：一般服务损害范围（例如，丢失所有访问、性能下降、从属应用程序受影响、观察到的客户影响）

优先级为 P0 或 P1 的所有分类为“问题”的事件，无论来源如何，都将记录在 Cloudflare 票务系统 JIRA 中。 某些警报将指示可能不会立即影响服务级别的状况，并在必要时将其归类为 P2 或 P3 优先级的问题。

JIRA 系统是所有事件信息的记录系统，并且有关问题的所有其他文档来源（例如警报历史记录、屏幕截图、工作日志、聊天对话）都会随附到为响应事件而创建的原始 JIRA 故障单上。

​​ 事件分类

确认警报后，SRE 立即通过将警报与类别和优先级相关联来对警报进行分类。  在为高优先级（P0 和 P1）问题创建新的 JIRA 故障单时，SRE 将立即通过包括其类别和优先级来确保对每个故障单进行正确的分类。

​​ 优先级

所有故障单将根据以下 4 个优先级进行分类。 列出的标准是一般准则。  下述条件可明确定义优先级；但是，根据 SRE 或 Cloudflare 管理蹭的判断，可以根据需要为问题分配更高的 优先级。

​​

类别

为进行正确的跟踪和通信，会将高优先级（P0 和 P1）问题分配给类别。这些类别（故障单标签）对应于 Cloudflare 的公共状态页面上列出的公开交流的类别。

低优先级（P2 和 P3）故障单可以使用特定于 Cloudflare 内的各种工程和非工程团队的标签和术语来分类。 这些标签和类别未在本文档中列出。

​​ 安全事件

必须要了解到，归类为“安全”类别的事件需要特殊的处理和程序。 这些事件应在此处记录，然后遵循 Cloudflare 信息安全团队定义的安全事件过程。

​​ 高严重性/优先级事件

P0 和 P1 事件显然对业务有更大的影响，因此，制定了一些特殊的前期要求以确保以最快的方式处理它们。

​​ 事件管理者

对于所有 P0 和 P1 问题，应立即联系当值事件管理者。 将发布事件管理者值班时间表，以确保 SRE 在任何给定时间都知道与谁联系。 事件管理者是负责以下各项事宜的重要资源：

• 验证问题的严重性
• 从问题提交到解决全程跟踪
• 代表客户的最大利益
• 记录所有操作和时间
• 指导工作人员朝着最快的解决方案努力
• 确保根据预定时间周期（或在状态更改时）将状态通知给客户和内部管理人员
• 在问题超过时间限制或未取得适当进展时执行客户端、内部或第三方升级
• 确保根据决议对故障单进行有意义的解释
• 在故障单关闭之前确保初始提交者同意问题已解决

​​ 事件沟通

事件期间的外部通信对于以下情况至关重要：

• 通知利益相关者 Cloudflare 已意识到该问题并正在寻求解决办法
• 向客户保证此事正在审查中，而 Cloudflare 将从客户的最大利益出发
• 问题不会不必要地拖延，并且会进行适当的升级
• 将重要事件通知关键内部利益相关者

事件期间的主要沟通类型包括：

一旦发现事件，CSUP 团队成员就会使用模板创建状态页。

​​ 事后审查

Cloudflare 认为，所有关键问题都绝不应该再次发生。 为此，我们将对所有 P0 问题发布事件报告 (IR)，其中包括问题的根本原因分析 (RCA) 以及导致事件的总体因素。发布所有 IR 之后，都会举行事后审查会议，工程师和管理人员将在会上审查 IR 的细节、RCA 的结论以及将采取的任何后续补救措施并达成一致，以确保问题情况不再发生。

​​ 问题管理和事后审查

问题管理与事件管理的不同之处在于，其主要目标是发现事件的根本原因及其后续解决和预防措施。

​​

根本原因分析和补救

​​ 问题故障单

RCA 是指“根本原因分析”报告。 Jira 问题故障单是记录和跟踪可能需要进行 RCA 的事件。 通过此过程，某个领域的主题专家 (SME) 将审查 P0 或 P1 问题，以寻找问题的根本原因。 确定根本原因后，SME 需要制定补救计划以进行解决。 最终的交付成果是一份记录良好的故障单，用于跟踪补救措施的完成情况，在需要时，也可以作为书面报告发送给内部团队和/或客户。

即使是由第三方提供商或供应商提供 RCA，以上几点也仍然适用。 当从第三方收到 RCA 信息时，我们必须确保使用所有相关信息（包括要跟踪的待决补救措施）更新问题故障单。

​​ IR 报告

事件报告 (“IR”) 是就问题与客户沟通的主要方法，可能包含故障单中所写的部分或全部内容。

根据问题的严重性和负责领域，撰写报告的人将有所不同。 报告草案完成后，必须请 Cloudflare 管理层对报告进行内容、承诺和专业介绍进行审核。 报告获得批准后，即可发布给客户。

​​ 问题审查

以上各节详细介绍了事件和根本原因的处理方法，以确保永久解决问题。 事件和问题管理过程的最后一部分是确保完成关键指标、趋势和报告，以确保过程得到正确遵循，满足 SLA，并且不遗漏深入问题。

​​ 报告

打开和关闭的故障单都需要报告的故障单条件包括以下内容：

• 严重性
• 类别/子类别
• 负责组
• 时长/开放天数

应尽可能以图形方式报告这些数据以显示可见趋势。 这些报告应发布给内部 Cloudflare经理和区域负责人。

​​ 分析和问责制

每个故障单的区域负责人不仅要负责确保故障单在规定或合理时间内关闭，而且还要负责检查报告并查找趋势、问题和重复问题。 基于此分析，应打开更多问题故障单以补救可能未通过 P0 或 P1 显现的任何问题。 这将允许持续改进，并应通过进一步处理根本原因最终减少新的故障单。

​​ 事件管理审查会议（事后）

在所有部门员工会议中，团队管理人都应审查故障单发开和趋势报告，具体目标如下：

• 讨论成功领域或顾虑领域
• 审查区域负责人的改进机会
• 就需要为补救跟踪打开新问题故障单的区域达成一致