> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/05-workflow/incident-response.md).

# 事故响应流程

生产事故发生时，AI 辅助根因分析的操作步骤，以及人工判断在哪些环节不能省略。

***

## 问题

事故场景下最危险的错误是：把 AI 生成的根因假设当作已确认的结论，然后基于错误的假设部署修复。AI 在模式匹配上很快，但它的"自信"不代表正确——它只是在已有训练数据中找到了最相似的模式。

生产环境的特殊性在于：每次事故的上下文组合几乎是唯一的。AI 找到的模式可能来自相似但不完全相同的场景，差异恰好就在根因所在的地方。

**规则**：AI 生成假设，人工验证假设，验证完成后才能定性根因。这条规则在时间压力下最容易被违反，也是最需要坚守的时候。

***

## 响应流程

### 第 1 步：收集上下文（人工）

在提交给 AI 分析之前，先整理以下信息：

* **错误日志**：完整的错误信息和堆栈，不要截断
* **时间线**：事故开始的时间点，与最近的变更记录（部署、配置变更、数据迁移）对照
* **影响范围**：哪些服务、哪些用户、何种程度的影响
* **已排查的内容**：已经确认不是根因的假设

这一步的输出是一份结构化的上下文摘要，而不是把原始日志全部粘贴给 AI。原始日志太长时，AI 会遗漏关键细节或抓错重点。

### 第 2 步：AI 根因分析

将结构化上下文提交给 AI，要求它：

```
给定以下错误信息、时间线和影响范围，生成可能的根因假设列表。
每个假设需要说明：
1. 假设的内容
2. 支持该假设的证据（来自已提供的上下文）
3. 验证该假设需要检查什么

不要只给一个假设，给出你认为可能性最高的 3-5 个，按可能性排序。
```

**为什么要多个假设**：单一假设会引发确认偏误——人工验证时会倾向于找支持它的证据，而忽略反驳证据。多个假设迫使验证过程是排除式的，而不是确认式的。

### 第 3 步：人工验证（人工）

逐一验证 AI 给出的假设。这一步不是"哪个看起来最像"，而是通过实际检查来排除：

* 检查对应的代码路径、配置、数据状态
* AI 辅助查找相关代码（"找所有处理这类请求的地方"）
* 对每个假设得出明确的"成立"或"不成立"结论，并记录依据

**如果所有假设都不成立**：回到第 2 步，提供新的约束（"以上假设均不成立，已确认 X 和 Y 正常，继续分析"）。

### 第 4 步：修复（AI 辅助，人工审查）

根因确认后：

1. 让 AI 生成修复方案，要求它同时说明方案的风险和局限
2. 人工审查修复方案，重点检查：是否只修复了症状而不是根因，是否可能引入新问题
3. 部署前准备回滚预案

**规则**：即使时间紧迫，修复方案也需要至少一人审查。独自部署 AI 生成的修复是高风险操作。

### 第 5 步：复盘（人工主导，AI 辅助整理）

事故解决后，在 24 小时内完成复盘记录：

```
事故时间线：[开始时间 → 发现时间 → 响应时间 → 解决时间]
根因：[经过验证的根因，一句话]
根因类别：[代码缺陷 / 配置错误 / 外部依赖 / 容量问题 / 人为操作]
修复内容：[做了什么]
防止复发：[流程或代码层面的改进，明确负责人和时间]
```

AI 可以帮助整理格式和生成时间线摘要，但根因定性和改进措施必须由人工确认。

***

## 事故响应的常见失败模式

**跳过收集步骤直接给 AI 分析**：AI 拿到不完整的上下文，生成不完整的假设，验证假设时发现漏了关键信息，时间浪费在来回补充上。

**把第一个 AI 假设当作答案**：直接部署基于未验证假设的修复，事故解决了但不知道真实根因，同类问题会再次出现。

**解决后不复盘**：改进措施停留在口头，下次事故重复同样的错误和时间浪费。

**复盘时 AI 定性根因**：AI 的根因分析是假设，复盘文档里写的是已验证的结论。混淆两者会在后续对这个事故的引用中传播错误信息。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/05-workflow/incident-response.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.