> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 处理一次线上事件：从告警到复盘

> 确认事件、评估影响、通知客户、跨信号定位原因、恢复服务并总结经验，始终以事件记录作为唯一主线。

事件之所以让人紧张，是因为好几件事必须同时发生：要有人接手，要通知客户，还要找到原因。始终保持一条主线：**告警** 中的那个事件。从状态页到复盘，其他一切都链接回它。

## 接手事件

从通知中打开事件，或打开 **告警 → 告警事件** 的 **等待确认** 标签页。在确认超时之前点击 **确认**。确认会停止升级，并向打开事件的每个人显示负责人，避免其他人同时做重复的工作。

多个事件由同一个原因引起时，确认最能说明原因的那一个，并在处理期间[静默](https://docs.molesignal.com/zh-Hans/alerting/silences.md#静默单个事件)其余事件。被[语义分组](https://docs.molesignal.com/zh-Hans/alerting/silences.md#语义分组)收到一起的事件可以通过 API 一起确认。

## 评估影响

在做任何改动之前，先阅读[事件详情](https://docs.molesignal.com/zh-Hans/alerting/incidents.md#事件详情)：

| 分区 | 回答的问题 |
| - | - |
| **触发查询** | 什么越过了阈值、越过多少、从什么时候开始？ |
| **影响范围** | 受影响的服务会波及哪些服务和页面？ |
| **样本会话** | 对用户体验事件，真实用户看到了什么？每个会话都有回放。 |
| **跨信号引用** | 涉及哪些服务、主机和链路？ |

查看受影响服务的 [SLO](https://docs.molesignal.com/zh-Hans/apm#服务等级目标)：燃烧率高意味着客户此刻就能感受到问题。

## 尽早通知客户

客户受到影响时，在原因查明之前就发布一个[状态页事件](https://docs.molesignal.com/zh-Hans/status-pages#事件生命周期)：

1. 以草稿创建事件，选择受影响的组件及其影响程度。
2. 以 **调查中** 状态发布第一条更新：客户看到了什么，以及下一次更新的时间。
3. 每次状态变化都追加一条更新：**已确认**、**监控中**、**已解决**。已发布的更新永远不会被修改，只能被新的更新接续。

[发布自动化](https://docs.molesignal.com/zh-Hans/status-pages#发布自动化)可以根据告警起草状态页事件并等待批准，让第一条更新在几秒内就准备好。

## 定位原因

保持事件的时间窗口，从症状一路追到原因：

* **打开触发查询** 重放触发事件的查询，**相关日志** 和 **相关指标** 打开它周边的上下文。日志、链路、指标和会话之间的跳转参见[跨信号关联](https://docs.molesignal.com/zh-Hans/correlation.md)。
* 查找最近的变更：服务的[发布时间线](https://docs.molesignal.com/zh-Hans/apm/deployments.md#发布时间线)，以及[应用性能发现附近的变更](https://docs.molesignal.com/zh-Hans/apm/insights.md#发现附近的变更)。
* 阅读 [AI 根因](https://docs.molesignal.com/zh-Hans/alerting/incidents.md#ai-根因)，或点击 **生成**。把它当作需要验证的线索，并评价为 **有帮助** 或 **没帮助**。
* 在服务页上用 **调查** 向 [Mole Agent](https://docs.molesignal.com/zh-Hans/agent) 提问，它会把服务健康、上下游和发现附加到对话中。

排查过程中，把每个假设及其证据记录到团队的事件频道中。复盘需要这条时间线。

## 先止血，再恢复

优先选择最快且安全的止血手段，例如回滚或关闭功能开关，而不是在压力下修复。止血之后：

* 观察触发查询恢复正常。规则满足恢复条件时，打开的事件会自动解决；已确认的事件需要有人点击 **解决**。
* 只是在重复已知问题的相关事件，用[静默单个事件](https://docs.molesignal.com/zh-Hans/alerting/silences.md#静默单个事件)屏蔽，而不是静默规则本身。
* 把状态页更新为 **监控中**，服务稳定一段时间后再更新为 **已解决**。

## 总结经验

几天之内在状态页事件上撰写[复盘](https://docs.molesignal.com/zh-Hans/status-pages#事故复盘)：发生了什么、影响、时间线、原因，以及后续的改进。评审期间保存为草稿，事件解决后再发布。Mole Agent 可以根据事件记录起草复盘。

然后用[洞察](https://docs.molesignal.com/zh-Hans/alerting/incidents.md#洞察)改进检测：**快速恢复事件** 和 **主要触发规则** 指向噪声规则，通知来得太晚则说明缺少规则或规则太慢。参见[让生产告警能够指导响应](https://docs.molesignal.com/zh-Hans/best-practices/actionable-alerts.md)。

## 验收标准

* 每个事件都在确认超时之内有了负责人。
* 面向客户的事件，客户在发问之前就从状态页得知了情况。
* 复盘写明了原因、影响、时间线，以及每项后续工作的负责人。
* 每项改进检测的后续工作都是一条具体的规则改动，并已在真实数据上测试。

## 相关指南

* [告警事件](https://docs.molesignal.com/zh-Hans/alerting/incidents.md)
* [状态页](https://docs.molesignal.com/zh-Hans/status-pages)
* [跨信号关联](https://docs.molesignal.com/zh-Hans/correlation.md)
* [搭建值班与通知](https://docs.molesignal.com/zh-Hans/best-practices/on-call-setup.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.