严重性级别

任何事件响应过程的第一步是确定实际构成事件的内容。然后，事件可以按严重性分类，通常使用“SEV”定义进行，编号越低的严重性越紧急。操作问题可以归类为这些严重性级别之一，通常您可以采取更具风险的措施来解决更高严重性的问题。任何高于SEV-3的事件都会自动被视为“重大事件”，并得到比正常事件更密集的响应。

始终假设最坏情况

如果您不确定事件的级别（例如不确定是SEV-2还是SEV-1），将其视为更高的级别。在事件期间不是讨论或争论严重性的时间，只需假设最高级别并在事后审查。

SEV-3可以是重大事件吗？

所有SEV-2都是重大事件，但并非所有重大事件都需要是SEV-2。如果您需要协调响应，即使是较低严重性的问题，也要触发我们的应急响应流程。事件指挥官可以决定是否需要全面的事件响应。

严重性 描述 典型响应
SEV-1

需要公开通知并与执行团队联络的严重问题。

  • 系统处于危急状态，正在积极影响大量客户。
  • 功能严重受损已久，违反了SLA。
  • 我们注意到了一个暴露客户数据的安全漏洞。

重大事件响应。

  • 在Slack中呼叫IC !ic page。
  • 参见事件期间。
  • 通知内部利益相关者。
  • 公开通知。
SEV-2

正在积极影响许多客户使用产品的关键系统问题。

  • 通知管道严重受损。
  • 事件响应功能（确认、解决等）严重受损。
  • Web应用对大多数/所有用户不可用或性能严重下降。
  • PagerDuty系统重大事件条件的监控受损。
  • PagerDuty员工认为需要事件响应的任何其他事件。

重大事件响应。

此行以上的任何事件都被视为“重大事件”。对于任何重大事件，都应触发我们的应急响应流程。
SEV-3

需要服务所有者立即关注的稳定性或轻微客户影响问题。

  • 部分功能丧失，不影响大多数客户。
  • 如果不采取措施，有可能成为SEV-2的问题。
  • 服务中没有冗余（再有一个节点故障将导致中断）。

高紧急度呼叫服务团队。

  • 将问题作为您的最高优先级处理。
  • 与受影响系统的工程师联络以确定原因。
  • 如果与最近部署相关，回滚。
  • 监控状态并注意是否/何时升级。
  • 如果您认为有可能升级，请在Slack中提及。
  • 必要时触发事件响应（!ic page）。
SEV-4

需要采取行动的轻微问题，但不影响客户使用产品。

  • 性能问题（延迟等）。
  • 单个主机故障（即集群中的一个节点）。
  • 延迟作业失败（不影响事件和通知管道）。
  • Cron失败（不影响事件和通知管道）。

低紧急度呼叫服务团队。

  • 将问题作为您的首要优先级处理（高于“正常”任务）。
  • 监控状态并注意是否/何时升级。
SEV-5

不影响客户使用产品的外观问题或错误。

  • 不影响系统立即使用能力的错误。

JIRA工单。

  • 创建JIRA工单并分配给受影响系统的所有者。

具体明确

这些严重性描述已从PagerDuty内部定义修改为更通用。对于您自己的文档，建议您使定义非常具体，通常指受影响的用户/账户的百分比。您通常希望您的严重性定义是基于指标的。