在事件报告中使用“五问法”分析
生成事件报告时，CloudWatch 调查功能可以执行“五问法”根本原因分析，以系统化地确定操作问题的根本原因。这种结构化方法能提供更深入的见解和可行的补救措施，以此增强事件报告。
此功能使用 Amazon Q 提供对话式聊天。登录 Amazon Web Services 管理控制台的用户必须具有以下权限：
{ "Sid" : "AmazonQAccess", "Effect" : "Allow", "Action" : [ "q:StartConversation", "q:SendMessage", "q:GetConversation", "q:ListConversations", "q:UpdateConversation", "q:DeleteConversation", "q:PassRequest" ], "Resource" : "*" }
您可以直接添加这些权限，也可以通过将托管式策略 AIOpsConsoleAdminPolicy 或 AIOpsOperatorAccess 附加到用户或角色来授予权限。
什么是“五问法”分析？
“五问法”是一种根本原因分析技术，通过反复询问“为什么”，从事件症状逐步深入至根本原因。每个答案都成为下一个问题的基础，由此创建一条逻辑链，以揭示真正的根本原因，而不仅仅是表面现象。
在生成事件报告期间，CloudWatch 调查功能会使用此方法来分析调查发现，并提供结构化的根本原因分析，该分析不局限于直接技术原因，更能识别流程、配置或系统性问题。
为事件报告带来的优势
在事件报告中包含“五问法”分析具有以下几点优势：
-
全面的根本原因确定：不局限于直接技术原因，识别潜在的流程或系统问题
-
切实可行的补救计划：提供具体、有针对性的措施以防问题再次发生，而非临时修复方案
-
组织学习：记录完整的因果链，供未来参考和团队知识共享
-
结构化分析：确保开展系统性调查，而不是临时解决问题
事件报告示例场景
数据库连接失败事件
初始事件：电子商务应用程序出现大范围 500 错误
-
一问：为什么用户收到 500 错误？ 因为应用程序无法连接到主数据库。
-
二问：为什么应用程序无法连接到数据库？ 因为数据库实例的可用连接耗尽。
-
三问：为什么数据库连接耗尽？ 因为批处理作业打开了大量连接但未正确关闭。
-
四问：为什么批处理作业未正确关闭连接？ 因为作业的错误处理未包含故障场景下的连接清理。
-
五问：为什么没有实施正确的错误处理？ 因为代码审查过程未包含对资源管理模式的特定检查。
根本原因：针对资源管理的代码审查标准不完善
建议措施：更新代码审查清单，实施连接池监控，添加自动化资源泄漏检测
性能下降事件
初始事件：流量高峰期间，API 响应时间从 200 毫秒增加至 5000 毫秒
-
一问：为什么响应时间增加？ 因为所有应用程序实例的 CPU 利用率均达到 100%。
-
二问：为什么自动扩缩没有添加更多实例？ 因为自动扩缩已触发，但新实例未通过运行状况检查。
-
三问：为什么新实例未通过运行状况检查？ 因为应用程序启动过程需要 8 分钟，超过了运行状况检查超时时间。
-
四问：为什么启动需要这么长时间？ 因为每次启动时，应用程序都会从 S3 下载大型配置文件。
-
五问：为什么自动扩缩配置没有考虑这种启动延迟？ 因为性能测试是在实例预热状态下进行的，而非冷启动。
根本原因：性能测试方法无法反映生产环境的自动扩缩场景
建议措施：纳入冷启动测试、优化应用程序启动、调整运行状况检查超时时间、实施配置缓存
包含分支分析的复杂事件
初始事件：OpenSearch Serverless 客户遭遇了可用性下降 48.3% 的情况长达 11 小时
主分析链：
-
一问：为什么客户遭遇服务降级？ 由于提取程序扩展不当，服务可用性降至 48.3%。
-
二问：为什么提取程序扩展不当？ 因为 CortexOperator 因可用区平衡计算错误，将提取程序从 223 个减少到 174 个。
-
三问：为什么 CortexOperator 错误计算可用区平衡？ 因为代码在升级到 1.17 版本后无法处理新的 Kubernetes 标签格式。
-
四问（分支 A – 技术分析）：为什么代码无法处理新的标签格式？ 因为代码期望使用“failure-domain.beta.kubernetes.io/zone”标签，但 Kubernetes 1.17 更改为 “topology.kubernetes.io/zone”。
-
五问（分支 A）：为什么没有实施向后兼容性？ 因为部署规划期间，审查的升级说明中未记录标签格式更改。
分支 B – 流程分析：
-
四问（分支 B – 流程分析）：为什么测试中未能发现此问题？ 因为集成测试使用的是带有旧标签格式的预配置集群。
-
五问（分支 B）：为什么测试未包含标签格式验证？ 因为测试环境设置未反映生产环境的 Kubernetes 版本升级顺序。
已确定根本原因：
-
技术：缺少对 Kubernetes 标签格式更改的向后兼容性
-
流程：测试方法未能验证版本升级的影响
综合补救计划：实施标签格式检测逻辑，增强升级测试程序，添加自动化兼容性验证，并建立版本更改影响评测流程。
使用引导式“五问法”工作流
CloudWatch 调查功能提供引导式“五问法”工作流，帮助您补充缺失的事实并加强事件报告。当系统发现增强根本原因分析的机会时，此功能将以建议工作流的形式出现。
交互式分析体验
CloudWatch 调查功能中的“五问法”分析采用基于聊天的交互式方法，引导您完成调查过程。这种对话方式有助于确保分析的全面性，同时维持问题之间的逻辑连贯性。
交互式体验的主要特点：
-
基于事实的初始化：系统会首先显示调查中的相关事实，并用其预填充明显答案，清晰区分基于事实的建议与基于推断的建议
-
引导式探究：对于每一问，系统都会根据现有事实提出答案，请求特定的其他上下文，并引导您在继续之前考虑重要方面
-
分支管理：当确定了多个影响因素时，系统会清晰地呈现分支选项，解释分支之间的关系，并帮助确定并行调查的优先顺序
-
渐进式验证：对于每个答案，系统都会重新表述答案以求清晰，寻求确认，突出关键见解，并将调查发现与更广泛的上下文联系起来
这种方法可确保您捕获所有相关信息，同时专注于最关键的因果关系。
访问指导式工作流：
-
在事件报告生成期间，查看右侧面板中的需要关注的事实部分。
-
在建议工作流下查找引导式“五问法”分析建议。
-
选择引导我，开始交互式“五问法”过程。
-
按照引导提示，系统地解决每一问，构建从症状到根本原因的完整因果链。
引导式工作流通过引导您完成“五问法”方法的每个步骤，帮助您捕获全面的根本原因信息。分析结果会自动整合到事件报告中，为事后审查和组织学习提供结构化文档。
您也可以通过聊天界面请求进行“五问法”分析，例如询问“对此事件执行‘五问法’分析”或“使用‘五问法’的根本原因是什么？”
处理具有多种原因的复杂事件
某些事件涉及多个影响因素，需要并行分析路径。CloudWatch 调查功能支持分支分析，以确保确定所有重要原因并加以解决。
需要分支分析的情况：
-
同时发生多个独立故障
-
不同的系统组件对客户产生了同样的影响
-
技术和流程故障都起着重要作用
-
级联失败产生了多条因果链
分支分析流程：
-
分支识别：系统识别多种原因汇聚或分歧的节点
-
并行调查：使用完整的“五问法”方法对每个分支进行分析
-
连接映射：记录分支之间的关系，以展示它们之间的交互方式
-
综合解决方案：补救计划需处理所有已确定的根本原因及其相互作用
这种全面的方法可确保对复杂事件进行深入分析，且最终补救计划能消除所有影响因素。
有效进行“五问法”分析的最佳实践
为使“五问法”分析在事件报告中发挥最大效用，请遵循以下基于操作经验得出的最佳实践：
问题表述准则
-
从客户影响入手：每次分析都从客户直接面对的问题开始，以保持对业务影响的关注
-
逐步深化技术细节：随着问题推进，从业务影响过渡到技术细节
-
保持逻辑连续性：确保每个答案都能自然引出下一个问题，避免逻辑断层
-
包含支持性证据：引用具体的指标、日志或时间线事件来验证每个答案
分析验证
使用以下标准验证“五问法”分析：
-
逻辑连贯性：从症状到根本原因进行清晰推进，不遗漏任何步骤
-
技术准确性：术语正确、系统行为描述准确、组件交互有效
-
完整性：分析解释所有观测到的症状，并得出根本原因，解决根本问题即可防止事件再次发生
-
可行性：确定的根本原因指向具体的、可行的补救措施
需要避免的常见陷阱
-
止步于症状：不要在第一次出现技术故障时就结束分析；应继续深入，直到找到系统性或流程性原因
-
归咎式分析：关注系统和流程故障，而非个人行为
-
单一路径思维：考虑多个影响因素，并在适当情况下使用分支分析
-
证据不足：确保每个答案都有来自调查的具体数据支持
与事件报告各部分整合
“五问法”分析与事件报告的其他部分整合，提供全面的文档：
-
时间线相关性：每一问都可以引用特定的时间线事件，为因果关系提供时间上下文
-
指标验证：答案得到指标和图表的支持，以证明所描述的技术行为
-
影响评测对齐：第一问与影响评测各部分中记录的客户影响指标直接关联
-
经验总结基础：通过“五问法”分析确定的根本原因为“经验总结”和“整改措施”部分提供直接依据
这种整合确保了事件报告的一致性，并为利益相关者提供了从初始症状到根本原因、再到补救计划的完整而连贯的叙述。