故障事件管理指南

本指南涵盖灵王 OPS 中完整的故障事件管理工作流程：从创建事件、关联告警，到运行复盘和跟踪 SLO 违规。

1. 事件与告警：区别是什么？

告警和事件在运营工作流程中承担不同的角色：

一个有用的心智模型： 告警是症状。事件是诊断和治疗方案。一个告警可能触发一个事件；反过来，一个事件可能汇总多个告警。

何时创建事件

当满足以下任一条件时创建事件：

• 问题需要超过一个人来解决
• 问题有用户可见的影响（收入损失、服务降级、数据完整性风险）
• 问题复杂或不明确，需要结构化调查
• 您的 SLA/SLO 面临违约风险
• 需要为该事件建立作战室或协调渠道

对于简单、快速解决的告警（如单个非关键进程重启），告警标注即可。

2. 创建事件

创建事件有两种主要方式：从告警一键创建，或从头手动创建。

2a. 从告警一键创建

当您在告警详情页并判断情况需要完整的事件处理时：

1. 点击告警详情页右上角的创建事件。
2. 出现预填充的事件表单：
3. 标题：从告警名称和关键标签自动派生（如 PaymentServiceDown @ production-checkout-01）
4. 严重级别：继承自告警严重级别（critical → SEV-1，warning → SEV-2，info → SEV-3）；可调整
5. 描述：预填充告警的 summary 和 description 标注
6. 关联告警：来源告警自动关联
7. 根据需要调整任何字段（见第3节字段定义）。
8. 点击创建事件。

您将立即被重定向到新的事件页面。

2b. 手动创建事件

有时需要在没有触发告警的情况下创建事件（例如，通过支持渠道报告的客户问题，或可能导致影响的计划内维护事件）。

1. 在左侧导航中进入事件 → 所有事件。
2. 点击右上角的 + 新建事件。
3. 填写必填字段（标题、严重级别、描述——见第3节）。
4. 您可以选择在此阶段关联相关告警（见第5节）。
5. 点击创建事件。

示例：数据库宕机导致事件

场景： 上午10:15值班工程师 @alice 收到多个告警：

• DatabaseConnectionErrors（critical）— 10:15:03
• ReplicationLagHigh（critical）— 10:15:08
• PrimaryDBDown（critical）— 10:15:12

@alice 在 PrimaryDBDown 告警上点击创建事件。系统：

• 创建标题为："PrimaryDBDown @ prod-db-primary" 的事件
• 严重级别：SEV-1（critical）
• 预填充告警标注中的描述
• 自动关联 PrimaryDBDown 告警

@alice 随后手动关联其他两个相关告警（见第5节）。事件现在涵盖所有三个信号。在接下来的2小时内，团队完成事件处理并进行复盘。

3. 事件字段

每个事件包含以下字段：

严重级别定义

4. 事件状态流转

事件遵循严格的三状态流转：

OPEN  →  ACKNOWLEDGED  →  RESOLVED

状态转换

打开 → 已确认： - 任何运维人员在事件上点击确认。 - 这通常由第一个响应者或接收事件的值班工程师完成。

已确认 → 已解决： - 主要响应者（或任何有权限的运维人员）点击解决。 - 只有在确认根本原因已修复且关联告警也在处理或已解决时，事件才应被解决。 - 解决后，事件进入复盘阶段（如适用）。

示例：状态转换

10:15:03  OPEN        @alice 创建事件（由 PrimaryDBDown 告警触发）
10:16:41  ACKNOWLEDGED @bob（值班 DBA）确认并开始调查
10:18:22  ANNOTATION  @bob："切换到只读副本，正在调查主库"
10:45:10  ANNOTATION  @carol："主库已恢复，正在切回"
11:02:33  RESOLVED    @bob 将事件标记为已解决

5. 将相关告警关联到事件

一个事件通常不会孤立于单个告警。多个告警可能从同一根本原因触发。关联它们有助于：

• 在调查期间关联信号
• 在一个地方查看所有受影响的指标
• 确保关闭事件时所有相关告警也得到解决
• 记录事件的完整范围

在事件创建期间关联告警

当从告警创建事件时（第2a节），来源告警自动关联。您可以在创建时通过表单的关联告警部分关联更多告警。

将告警关联到现有事件

1. 打开事件详情页。
2. 滚动到关联告警部分。
3. 点击 + 关联告警。
4. 通过告警 ID、告警名称搜索，或按标签/时间范围筛选。
5. 选择要关联的告警并点击关联。

您也可以从告警列表批量关联告警：

1. 在告警列表中选择一个或多个告警。
2. 在操作栏中点击关联到事件。
3. 搜索并选择目标事件。

从告警页面关联告警

1. 在告警详情页，滚动到相关事件部分（如果告警已关联则可见）。
2. 点击关联到另一个事件。
3. 选择现有事件或创建新事件。

示例：将三个告警关联到一个事件

继续数据库宕机的示例：

• 事件："PrimaryDBDown @ prod-db-primary"（SEV-1）创建于 10:15:03
• 自动关联： PrimaryDBDown（告警 ID：ALT-8821）
• @alice 手动关联：
• DatabaseConnectionErrors（ALT-8819）— 847 次连接失败
• ReplicationLagHigh（ALT-8823）— 延迟峰值达 180 秒

三个告警现在都显示在事件的关联告警部分。解决事件时，运维人员应确认这些告警也朝解决方向推进。

6. 事件时间线 / 审计日志

每个事件维护所有事件的按时间顺序时间线。这既是审计日志，也是主要的交接文档。

时间线条目

以下事件自动记录：

添加标注（备注）

标注是人类可读的备注，记录调查、决策和采取的行动。

1. 打开事件详情页。
2. 滚动到时间线部分。
3. 点击 + 添加备注。
4. 输入您的备注。使用 @用户名 来提及团队成员，并包含时间戳以保持清晰。
5. 点击保存。

带标注的示例时间线

10:15:03  CREATED          @alice 创建事件
10:15:03  LINKED ALERT     PrimaryDBDown (ALT-8821) 已关联
10:16:41  ACKNOWLEDGED     @bob 确认
10:16:41  ASSIGNED         @bob 被指派为响应者
10:18:22  ANNOTATION       @bob："DB 主库通过 VIP 不可达。正在检查网络路径。"
10:22:15  LINKED ALERT     DatabaseConnectionErrors (ALT-8819) 已关联
10:23:01  LINKED ALERT     ReplicationLagHigh (ALT-8823) 已关联
10:25:47  ANNOTATION       @bob："识别到脑裂场景。正在启动手动故障转移。"
10:31:10  ANNOTATION       @carol："副本-02 升级为主库完成。正在监控。"
10:45:00  ANNOTATION       @bob："所有写入流量已恢复。正在观察复制延迟恢复。"
10:58:22  ANNOTATION       @alice："已确认：故障转移期间丢失 12 笔结账交易。正在升级到支付团队。"
11:02:33  RESOLVED         @bob 解决事件（持续时间：1小时47分30秒）

完整时间线成为复盘的主要输入。

7. 事件指派和升级

指派事件

指派人字段指定负责解决事件的主要人员。

• 点击事件详情页或事件列表上的指派按钮。
• 搜索并选择用户。
• 指派可以随时更改（例如，交接给专业人员时）。

团队字段指定所属团队，用于路由和统计。

升级

如果主要被指派人无法在 SLA 窗口内解决事件，或者严重级别需要更广泛的参与，则进行升级。

升级路径（每个组织可配置）：

1. Level 1 → Level 2： SEV-1 在超过 15 分钟未解决时自动寻呼副值班。
2. 团队升级： SEV-2/SEV-3 在 30 分钟内未确认时通知团队负责人。
3. 管理升级： SEV-1 在超过 1 小时未解决时升级到值班工程经理。

示例：升级流程

10:15  @alice 为主数据库宕机创建 SEV-1 事件。@bob（值班 DBA）被指派。
10:17  @bob 确认，开始调查。
10:31  @bob 在发现脑裂需要第三方意见后升级到 @carol（DBA 负责人）。
10:35  @carol 加入作战室，接管协调。
11:02  @carol 将事件标记为已解决。

8. 复盘

复盘是在事件解决后进行的结构化审查，旨在找出根本原因、评估响应质量，并提取预防行动项。

何时进行复盘

以下情况必须进行复盘：

• 所有 SEV-1 事件
• 持续时间超过 4 小时的 SEV-2 事件
• 任何有用户可见影响或数据丢失的事件
• 反复发生的事件（相同告警/根本原因多次出现）

复盘字段

进行复盘

1. 在解决后48 小时内安排——趁细节还记忆犹新。
2. 邀请所有响应者和任何受影响的利益相关者。
3. 共同审查事件时间线。
4. 协作填写复盘文档。
5. 审查并最终确定行动项——确保每个都有明确的负责人和截止日期。
6. 与更广泛的团队分享复盘结果。

示例：数据库宕机复盘

事件： PrimaryDBDown @ prod-db-primary（SEV-1）
持续时间： 1小时47分（10:15:03 – 11:02:33）
受影响： 结账服务，约 12,000 名用户经历交易失败

摘要：
主 PostgreSQL 数据库由于主库与其隔离代理之间网络分区导致的脑裂场景而变得不可达。自动故障转移未能触发，需要手动干预来提升副本。在 1 小时 47 分钟的中断期间，约 12,000 笔结账交易受影响，847 笔支付处理失败。

根本原因：
隔离代理由于常规维护窗口期间意外的网络拓扑变化而失去仲裁，导致其错误地认为与主库失去联系。同时，主库继续接受写入，造成脑裂状态。自动故障转移机制未考虑此特定网络分区模式。

行动项：

9. 事件统计

事件统计仪表板提供整个组织的运营健康指标。通过事件 → 统计访问。

关键指标

按严重级别的 MTTR

按严重级别细分的 MTTR（平均解决时间）是关键的 SLO/SLA 指标：

按团队的事件

用于了解哪些服务或团队有最高的运营负载：

此数据推动可靠性工作的优先级排序和复盘行动项的后续跟进。

10. SLO 违规跟踪

当事件持续时间超过配置的 SLA 目标时，它被标记为 SLO 违规。这会触发额外的可见性和升级。

SLO 违规检测如何工作

每个事件都有基于严重级别的 SLA 目标（确认和解决窗口）。系统持续监控打开的事件：

• 如果事件在 SLA 确认窗口内未确认，则标记为 TTA 违规（超过平均确认时间）。
• 如果事件在 SLA 解决窗口内未解决，则标记为 TTR 违规（超过平均解决时间）。

视觉指示器

在事件列表和详情页上，违规事件会高亮显示：

• 红色边框/徽章表示 SLA 违规
• 违规倒计时计时器显示事件已超过 SLA 多长时间
• 通知已发送给所属团队和管理升级路径

SLO 违规时间线

10:15:03  INCIDENT OPEN         SEV-1 事件已创建（SLA：确认 < 5分钟，解决 < 1小时）
10:20:03  TTA BREACH             事件在 5 分钟 SLA 内未确认
10:20:05  NOTIFICATION SENT      值班经理因 TTA 违规被呼叫
10:20:41  INCIDENT ACKNOWLEDGED  @bob 确认（超过 TTA SLA 26 分钟）
11:02:33  INCIDENT RESOLVED       1小时47分后解决（超过 TTR SLA 47 分钟）
11:02:35  SLO BREACH RECORDED    违规事件已记录用于报告

SLO 违规报告

SLO 违规报告（通过事件 → 统计 → SLO 违规访问）显示：

• 周期内的总 TTA 违规和 TTR 违规
• 违规的严重级别细分
• 违规最多的团队
• 平均违规持续时间
• 季度环比趋势

违规被分类为可避免的（响应失败）或不可避免的（复杂的、新发的事件需要时间诊断）。此区分在复盘审查期间进行。

SLO 违规后的行动

1. 立即： 值班经理自动收到通知。
2. 24 小时内： 简要事件审查以确定违规是否可避免。
3. 复盘： 所有 SEV-1 违规无论持续时间如何都需要复盘（见第8节）。
4. 行动项： 如果违规是由流程或工具缺口造成的，必须创建并跟踪特定行动项直至完成。

快速参考

有关告警到事件路由规则和自动事件创建策略的信息，请参见通知配置。