严重程度

任何事件响应过程中的第一步是确定实际的构成事件。然后可以通过严重程度对事件进行分类，通常通过使用“ SEV”定义来完成，而编号较低的严重性更为紧迫。可以将操作问题分类为这些严重程度之一，通常您能够采取更风险的举动来解决更高的严重性问题。SEV-3上方的任何东西都被视为“重大事件”，并且比正常事件获得更密集的响应。

始终假设最糟糕的

如果您不确定事件是哪个级别（例如，不确定SEV-2或SEV-1），将其视为较高的人。在事件期间，不是时候讨论或提起诉讼，只要在验尸期间提出最高和审查即可。

SEV-3可以成为重大事件吗？

所有SEV-2都是主要事件，但并非所有重大事件都必须是SEV-2。如果您需要协调的响应，即使对于较低的严重性问题，也会触发我们的事件响应过程。事件指挥官可以确定是否需要完全事件响应。

严重程度 描述 典型的响应
Sev-1

保证公众通知和与执行团队联络的关键问题。

  • 该系统处于关键状态，正在积极影响大量客户。
  • 很长一段时间以来，功能一直严重受损，破坏了SLA。
  • 曝光客户数据的安全漏洞引起了我们的注意。

主要事件响应。

  • Slack中的一个IC！IC页。
  • 看在事件中。
  • 通知内部利益相关者。
  • 公共通知。
Sev-2

关键系统问题会积极影响许多客户使用该产品的能力。

  • 通知管道严重受损。
  • 事件响应功能（ACK，Resolve等）受到严重损害。
  • Web应用程序不可用，或者对于大多数/所有用户而言都经历了严重的性能下降。
  • 监测针对主要事件条件的PAGERDUTY系统受到损害。
  • Pagerduty员工认为对事件响应所必需的任何其他事件。

主要事件响应。
这条线之上的任何东西都被认为是“重大事件”。我们的事件响应过程应针对任何重大事件触发。
Sev-3

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

  • 部分功能丧失，不影响大多数客户。
  • 如果什么也没做，有可能成为SEV-2的可能性。
  • 服务中没有冗余（多1个节点会导致中断）。

服务团队的高温页面。

  • 将问题作为您的重中之重。
  • 与受影响系统的工程师联系以识别原因。
  • 如果与最近部署有关，请回滚。
  • 监视状态并注意是否/何时升级。
  • 如果您认为它有可能升级，请提及Slack。
  • 如有必要，触发事件响应（！IC页）。
SEV-4

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

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

低野蛮网页到服务团队。

  • 将问题作为您的第一个优先级（“正常”任务）。
  • 监视状态并注意是否/何时升级。
SEV-5

美容问题或错误，不影响客户使用产品的能力。

  • 错误不会影响使用系统的直接能力。

Jira票。

  • 创建一个JIRA票并分配给受影响系统的所有者。

请明确点

这些严重性描述已从Pagerduty的内部定义更改为更通用。对于您自己的文档，鼓励您将定义非常具体，通常是指受影响的用户/帐户的百分比。您通常希望您的严重性定义是按公制驱动的。

Baidu