# 在事件报告中使用“五问法”分析
<a name="incident-report-5whys"></a>

生成事件报告时，CloudWatch 调查功能可以执行“五问法”根本原因分析，以系统化地确定操作问题的根本原因。这种结构化方法能提供更深入的见解和可行的补救措施，以此增强事件报告。

此功能使用 Amazon Q 提供对话式聊天。登录 AWS 管理控制台的用户必须具有以下权限：

```
{ 
    "Sid" : "AmazonQAccess",
    "Effect" : "Allow",
    "Action" : [
       "q:StartConversation", 
       "q:SendMessage", 
       "q:GetConversation", 
       "q:ListConversations", 
       "q:UpdateConversation", 
       "q:DeleteConversation", 
       "q:PassRequest" 
     ],
    "Resource" : "*"
 }
```

您可以直接添加这些权限，也可以通过将托管式策略 [AIOpsConsoleAdminPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html) 或 [AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html) 附加到用户或角色来授予权限。

## 什么是“五问法”分析？
<a name="5whys-overview"></a>

“五问法”是一种根本原因分析技术，通过反复询问“为什么”，从事件症状逐步深入至根本原因。每个答案都成为下一个问题的基础，由此创建一条逻辑链，以揭示真正的根本原因，而不仅仅是表面现象。

在生成事件报告期间，CloudWatch 调查功能会使用此方法来分析调查发现，并提供结构化的根本原因分析，该分析不局限于直接技术原因，更能识别流程、配置或系统性问题。

## 为事件报告带来的优势
<a name="why-5whys-incidents"></a>

在事件报告中包含“五问法”分析具有以下几点优势：
+ **全面的根本原因确定**：不局限于直接技术原因，识别潜在的流程或系统问题
+ **切实可行的补救计划**：提供具体、有针对性的措施以防问题再次发生，而非临时修复方案
+ **组织学习**：记录完整的因果链，供未来参考和团队知识共享
+ **结构化分析**：确保开展系统性调查，而不是临时解决问题

## 事件报告示例场景
<a name="5whys-incident-examples"></a>

### 数据库连接失败事件
<a name="example-database-outage"></a>

**初始事件：**电子商务应用程序出现大范围 500 错误

1. **一问：**为什么用户收到 500 错误？ 因为应用程序无法连接到主数据库。

1. **二问：**为什么应用程序无法连接到数据库？ 因为数据库实例的可用连接耗尽。

1. **三问：**为什么数据库连接耗尽？ 因为批处理作业打开了大量连接但未正确关闭。

1. **四问：**为什么批处理作业未正确关闭连接？ 因为作业的错误处理未包含故障场景下的连接清理。

1. **五问：**为什么没有实施正确的错误处理？ 因为代码审查过程未包含对资源管理模式的特定检查。

**根本原因：**针对资源管理的代码审查标准不完善

**建议措施：**更新代码审查清单，实施连接池监控，添加自动化资源泄漏检测

### 性能下降事件
<a name="example-auto-scaling"></a>

**初始事件：**流量高峰期间，API 响应时间从 200 毫秒增加至 5000 毫秒

1. **一问：**为什么响应时间增加？ 因为所有应用程序实例的 CPU 利用率均达到 100%。

1. **二问：**为什么自动扩缩没有添加更多实例？ 因为自动扩缩已触发，但新实例未通过运行状况检查。

1. **三问：**为什么新实例未通过运行状况检查？ 因为应用程序启动过程需要 8 分钟，超过了运行状况检查超时时间。

1. **四问：**为什么启动需要这么长时间？ 因为每次启动时，应用程序都会从 S3 下载大型配置文件。

1. **五问：**为什么自动扩缩配置没有考虑这种启动延迟？ 因为性能测试是在实例预热状态下进行的，而非冷启动。

**根本原因：**性能测试方法无法反映生产环境的自动扩缩场景

**建议措施：**纳入冷启动测试、优化应用程序启动、调整运行状况检查超时时间、实施配置缓存

### 包含分支分析的复杂事件
<a name="example-complex-branch"></a>

**初始事件：**OpenSearch Serverless 客户遭遇了可用性下降 48.3% 的情况长达 11 小时

**主分析链：**

1. **一问：**为什么客户遭遇服务降级？ 由于提取程序扩展不当，服务可用性降至 48.3%。

1. **二问：**为什么提取程序扩展不当？ 因为 CortexOperator 因可用区平衡计算错误，将提取程序从 223 个减少到 174 个。

1. **三问：**为什么 CortexOperator 错误计算可用区平衡？ 因为代码在升级到 1.17 版本后无法处理新的 Kubernetes 标签格式。

1. **四问（分支 A – 技术分析）：**为什么代码无法处理新的标签格式？ 因为代码期望使用“failure-domain.beta.kubernetes.io/zone”标签，但 Kubernetes 1.17 更改为 “topology.kubernetes.io/zone”。

1. **五问（分支 A）：**为什么没有实施向后兼容性？ 因为部署规划期间，审查的升级说明中未记录标签格式更改。

**分支 B – 流程分析：**

1. **四问（分支 B – 流程分析）：**为什么测试中未能发现此问题？ 因为集成测试使用的是带有旧标签格式的预配置集群。

1. **五问（分支 B）：**为什么测试未包含标签格式验证？ 因为测试环境设置未反映生产环境的 Kubernetes 版本升级顺序。

**已确定根本原因：**
+ 技术：缺少对 Kubernetes 标签格式更改的向后兼容性
+ 流程：测试方法未能验证版本升级的影响

**综合补救计划：**实施标签格式检测逻辑，增强升级测试程序，添加自动化兼容性验证，并建立版本更改影响评测流程。

## 使用引导式“五问法”工作流
<a name="accessing-5whys"></a>

CloudWatch 调查功能提供引导式“五问法”工作流，帮助您补充缺失的事实并加强事件报告。当系统发现增强根本原因分析的机会时，此功能将以建议工作流的形式出现。

### 交互式分析体验
<a name="interactive-analysis"></a>

CloudWatch 调查功能中的“五问法”分析采用基于聊天的交互式方法，引导您完成调查过程。这种对话方式有助于确保分析的全面性，同时维持问题之间的逻辑连贯性。

**交互式体验的主要特点：**
+ **基于事实的初始化**：系统会首先显示调查中的相关事实，并用其预填充明显答案，清晰区分基于事实的建议与基于推断的建议
+ **引导式探究**：对于每一问，系统都会根据现有事实提出答案，请求特定的其他上下文，并引导您在继续之前考虑重要方面
+ **分支管理**：当确定了多个影响因素时，系统会清晰地呈现分支选项，解释分支之间的关系，并帮助确定并行调查的优先顺序
+ **渐进式验证**：对于每个答案，系统都会重新表述答案以求清晰，寻求确认，突出关键见解，并将调查发现与更广泛的上下文联系起来

这种方法可确保您捕获所有相关信息，同时专注于最关键的因果关系。

**访问指导式工作流：**

1. 在事件报告生成期间，查看右侧面板中的**需要关注的事实**部分。

1. 在**建议工作流**下查找**引导式“五问法”分析**建议。

1. 选择**引导我**，开始交互式“五问法”过程。

1. 按照引导提示，系统地解决每一问，构建从症状到根本原因的完整因果链。

引导式工作流通过引导您完成“五问法”方法的每个步骤，帮助您捕获全面的根本原因信息。分析结果会自动整合到事件报告中，为事后审查和组织学习提供结构化文档。

您也可以通过聊天界面请求进行“五问法”分析，例如询问“对此事件执行‘五问法’分析”或“使用‘五问法’的根本原因是什么？”

## 处理具有多种原因的复杂事件
<a name="branch-analysis"></a>

某些事件涉及多个影响因素，需要并行分析路径。CloudWatch 调查功能支持分支分析，以确保确定所有重要原因并加以解决。

**需要分支分析的情况：**
+ 同时发生多个独立故障
+ 不同的系统组件对客户产生了同样的影响
+ 技术和流程故障都起着重要作用
+ 级联失败产生了多条因果链

**分支分析流程：**

1. **分支识别**：系统识别多种原因汇聚或分歧的节点

1. **并行调查**：使用完整的“五问法”方法对每个分支进行分析

1. **连接映射**：记录分支之间的关系，以展示它们之间的交互方式

1. **综合解决方案**：补救计划需处理所有已确定的根本原因及其相互作用

这种全面的方法可确保对复杂事件进行深入分析，且最终补救计划能消除所有影响因素。

## 有效进行“五问法”分析的最佳实践
<a name="5whys-best-practices"></a>

为使“五问法”分析在事件报告中发挥最大效用，请遵循以下基于操作经验得出的最佳实践：

### 问题表述准则
<a name="question-formulation"></a>
+ **从客户影响入手**：每次分析都从客户直接面对的问题开始，以保持对业务影响的关注
+ **逐步深化技术细节**：随着问题推进，从业务影响过渡到技术细节
+ **保持逻辑连续性**：确保每个答案都能自然引出下一个问题，避免逻辑断层
+ **包含支持性证据**：引用具体的指标、日志或时间线事件来验证每个答案

### 分析验证
<a name="validation-criteria"></a>

使用以下标准验证“五问法”分析：
+ **逻辑连贯性**：从症状到根本原因进行清晰推进，不遗漏任何步骤
+ **技术准确性**：术语正确、系统行为描述准确、组件交互有效
+ **完整性**：分析解释所有观测到的症状，并得出根本原因，解决根本问题即可防止事件再次发生
+ **可行性**：确定的根本原因指向具体的、可行的补救措施

### 需要避免的常见陷阱
<a name="common-pitfalls"></a>
+ **止步于症状：**不要在第一次出现技术故障时就结束分析；应继续深入，直到找到系统性或流程性原因
+ **归咎式分析**：关注系统和流程故障，而非个人行为
+ **单一路径思维**：考虑多个影响因素，并在适当情况下使用分支分析
+ **证据不足**：确保每个答案都有来自调查的具体数据支持

### 与事件报告各部分整合
<a name="5whys-integration"></a>

“五问法”分析与事件报告的其他部分整合，提供全面的文档：
+ **时间线相关性**：每一问都可以引用特定的时间线事件，为因果关系提供时间上下文
+ **指标验证**：答案得到指标和图表的支持，以证明所描述的技术行为
+ **影响评测对齐**：第一问与影响评测各部分中记录的客户影响指标直接关联
+ **经验总结基础**：通过“五问法”分析确定的根本原因为“经验总结”和“整改措施”部分提供直接依据

这种整合确保了事件报告的一致性，并为利益相关者提供了从初始症状到根本原因、再到补救计划的完整而连贯的叙述。