客户事件管理策略
了解 Cloudflare 如何处理影响其生产环境的事件以及 Cloudflare 将这些事件的性质和影响传达给 Enterprise 客户的方式。
目的
Cloudflare 认为，开放性和透明性是我们提供服务所固有的，并致力于让我们的客户和整个 Internet 社区对我们树立信任。 Cloudflare 运营着一个全球网络，该网络影响着全球数亿人口的生活和繁荣，因此，我们非常注意这一责任。
本标准操作程序 (SOP) 定义了 Cloudflare 如何处理影响其生产环境的所有事件和问题，以及 Cloudflare 如何将这些事件的性质和影响传达给计划内和计划外的 Enterprise 客户，无论其严重性如何。 本程序指定了如何一致地开展这些工作，以便
- 最大限度地加长环境正常运行时间，
- 最大限度地减少对客户的影响，
- 减少维修时间，以及
- 与我们的客户和 Internet 社区共享信息。
范围
此 SOP 适用于 Cloudflare 客户和客户使用的客户服务。SOP 适用于 Cloudflare 的所有客户生产环境，包括：
- Cloudflare 的公共网站 ( www.cloudflare.com)
- Cloudflare 的 API（应用程序编程接口）
- 站外第三方接口（例如信用卡授权等）
- Cloudflare 拥有或管理的用于生产服务的网络基础架构
- 影响 Cloudflare 生产的任何部分的供应商软件、硬件和服务
背景
Cloudflare 的宗旨是构建更好的互联网。为了向数百万互联网用户提供更好的体验，Cloudflare 的内部运营必须遵循出色的服务交付流程和程序。 因此，Cloudflare 的程序遵循许多行业标准的最佳做法，其中一些遵循信息库基础结构技术 (ITIL) 的模式。 该 SOP 遵循 ITIL 问题管理方法的最佳做法。
定义
关键事件术语的类别： 所有事件都是可以引发警报的条件；有些警报是值得注意的事件（有些不是）；必须对所有事件进行分类（有时是通过自动化，有时是通过人机交互）；有些事件是问题；问题中有一些是“重大”问题，并且会激发状态页更新；一些重大事件具有较高的优先级 (P1)，这需要创建事件报告。
关键术语：
术语 | 定义 |
事件 | Cloudflare 的生产应用程序或系统之一可以记录的任何可识别的离散事物 |
警告 | 通过 Cloudflare 的一个监视系统识别并传达、有潜在利害关系的事件 |
事件 | 极有可能影响 Cloudflare 的生产系统的报告或警报，或者仅在很短时间内存在的警报状况 - 因为在确定问题状况之前即恢复了受影响的服务的运行状况 |
问题 | 已识别、已分类的事件，对 Cloudflare 生产系统或应用程序的最佳运行状况和/或性能产生负面影响 |
事件报告 | 描述服务问题性质、Cloudflare 对问题的整体回应以及减少或消除未来影响的工作的公开报告 |
事后审查 | 针对严重和/或关键问题发起的审查会议。 所有事后审查会议着重于由技能或经验适合解决问题本质的 Cloudflare 工程师撰写的事件报告的详细信息。 |
SRE | 系统可靠性工程师是负责所有事件的一级支持的小组 |
CSUP | 客户支持小组是负责响应所有客户生成的请求、并负责在发现任何问题期间进行所有客户沟通的团队。 |
JIRA | 用于跟踪事件、工单和问题的 Cloudflare 票务系统 |
严重性/优先级 | 根据影响 Cloudflare 网络和客户的问题的严重性，“P0、P1、P2 或 P3”的值 |
SLA | 服务级别协议 - 特定服务水平的内部或合同义务（通常以每单位时间的行动来衡量） |
SLO | 服务级别目标 - 特定服务水平的内部或合同目标（通常以每单位时间的行动来衡量） |
事件指挥员 | 负责确保正确解决问题、守时、上报、向客户通报最新消息并根据需要接洽其他资源的 Cloudflare 资源 |
Internet 社区 | Cloudflare 的主要利益相关者群体。 Cloudflare 共保护和优化了超过 4600000 个网站，并且平均每个互联网用户每周与 Cloudflare 网站互动超过 500 次。 |
第三方 | 与 CloudFlare 合作向客户交付系统或服务的非 Cloudflare 供应商或服务提供商 |
利益相关者 | 受事件影响的个人、团体或公司，例如提供者（例如 Cloudflare、第三方）或消费者（客户） |
RCA | 根本原因分析 - 彻底检查问题的根本原因 |
补救措施 | 解决问题根本原因并确保不会再次发生的所有必要步骤 |
状态页 | Cloudflare 用于公开共享有关其服务交付以及任何影响 Cloudflare 服务的事件或问题的信息的主要工具： https://www.cloudflarestatus.com 状态页由第三方 (Statuspage.io) 托管，该第三方不依赖 Cloudflare 的服务运营。 |
角色和责任
以下角色和责任与 Cloudflare 中的事件管理相关联：
角色 | 责任 |
Cloudflare 管理层 | 审查并批准程序。 确保所有工作人员都接受过程序方面的培训。 必要时通知客户和第三方他们在程序中的角色。 启动并监督事后审查以获取关键的事件报告。 |
当值 SRE | 指派一位或多位 SRE 值班，以响应所有紧急警报。 识别并响应事件，评估事件的严重性并分类，以及将影响事件升级为问题。 从头到尾对问题进行升级和管理。 |
当值网络工程师 | 指派一位或多位网络工程师值班，以响应关键警报。 与 SRE 团队进行协调，后者会在发现任何问题时指定主要的事件管理者。 |
当值 CSUP | 指派一位或多位 CSUP 工程师值班，以响应所有客户要求。 在发现问题期间负责所有客户沟通。 负责传达所有维护计划。 |
SRE 团队 | 支持当值 SRE 的工作的整个系统可靠性工程团队。 在发现问题期间承担事件管理者的角色。 实施适当的 Cloudflare 支持的生产更改以解决问题。 |
Cloudflare 工程团队 （DBA、网络、nginx、安全性等） | 解决问题期间，支持事件管理者。 如果需要，加入沟通通话。 确保在诊断和更正问题时捕获到文档，并适当上报至其他责任组。 根据 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 | 完全无法访问 Cloudflare 应用程序或 API。 对 Cloudflare 应用程序或 API 的访问不畅（在全球范围内或从任何主要地区进行评估，⪯98%）。 完全失去对 1 级数据中心的访问权限或性能严重降低。 任何 1 级全球传输提供商的性能降低（全球 20% 的数据包丢失或任何主要地区的 30% 数据包丢失）。 对任何关键系统的访问不畅或性能下降 |
P1 | 间歇性或恶化的全站范围的性能降级。 失去重要功能，例如报告。 从社交媒体或外部 CloudFlare 网站之一（例如 spaCloudflare.com 、 salonCloudflare.com 等）无法访问 Cloudflare 应用程序。 重要的站外第三方接口中断。 对于 Enterprise 客户或分销合作伙伴之一，站点无法运行。 客户数据损坏或丢失。 |
P2 | 零星或局部性能问题。 尚未对客户端产生明显影响的系统问题（例如高 CPU）。 单客户端中断/降级。 |
P3 | 对最终用户影响很小或没有影响的运营问题、程序问题或服务请求，可以根据实际情况进行处理。 尚未检查或分配严重性级别的所有故障单分配到的默认严重性。 |
类别
为进行正确的跟踪和通信，会将高优先级（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，并且不遗漏深入问题。
报告
打开和关闭的故障单都需要报告的故障单条件包括以下内容：
- 严重性
- 类别/子类别
- 负责组
- 时长/开放天数
应尽可能以图形方式报告这些数据以显示可见趋势。 这些报告应发布给内部 Cloudflar e经理和区域负责人。
分析和问责制
每个故障单的区域负责人不仅要负责确保故障单在规定或合理时间内关闭，而且还要负责检查报告并查找趋势、问题和重复问题。 基于此分析，应打开更多问题故障单以补救可能未通过 P0 或 P1 显现的任何问题。 这将允许持续改进，并应通过进一步处理根本原因最终减少新的故障单。
事件管理审查会议（事后）
在所有部门员工会议中，团队管理人都应审查故障单发开和趋势报告，具体目标如下：
- 讨论成功领域或顾虑领域
- 审查区域负责人的改进机会
- 就需要为补救跟踪打开新问题故障单的区域达成一致