缺陷根本原因分析（RCA）提示词
该提示词可生成工程维度的根本原因分析文档。它能将故障场景转化为具有明确故障机制和防范措施的可执行复盘（Post-mortem）报告。
何时使用
当生产环境发生意外故障，且你需要一份结构化、不指责（blame-free）的复盘文档时使用此提示词。在分发给工程相关方之前，请将文中的故障细节替换为你自己的堆栈跟踪、日志和遥测数据。
提示词内容
## Role
扮演一名主任级站点可靠性工程师（Staff Reliability Engineer）。运用严谨的诊断判断力，同时确保技术解释对于工程师和跨职能合作伙伴而言都清晰易懂。
## Context
数字结账平台 KitePay 的主 API 集群遭遇了持续 27 分钟的支付处理中断。错误遥测数据显示，在部署 v2.14.0 版本后，HTTP 504 网关超时（Gateway Timeout）急剧激增。该版本在令牌授权期间，对 `merchant_settlements` 表引入了未建索引的外键查找，耗尽了 PostgreSQL 连接池。回滚到 v2.13.9 后超时问题得以解决。
## Objective
输出一份完整的根本原因分析（RCA）报告，解释代码变更如何引发数据库连接耗尽、故障是如何被缓解的，以及如何防止问题再次发生。
## Audience
主要读者为后端工程师和工程经理。提供足够充分的架构细节来支撑后续整改工作的合理性，避免不必要的理论说教。
## Requirements
一份 400–600 字的 RCA 文档，包含：故障摘要表；涵盖发现、响应和解决的时间线；使用 5 Whys 框架的技术根本原因剖析；已完成的临时缓解措施；以及长期的预防性行动。包含明确的数据库查询与索引优化建议。
## Constraints
不得虚构未提及的基础设施组件、随意的延迟数据、客户赔偿金额或未经验证的服务依赖项。将技术结论严格限制在所提供的数据库和连接池故障范围内。明确将推测性因素标记为未确认的假设。
## Tone & style
保持客观、不带指责色彩且分析精确。使用通俗的技术语言、简明的要点列表和清晰的结构层级。避免防御性质的说辞、含糊其辞和模糊的保证。
## Output format
首先使用清晰的 Markdown 标题呈现 RCA 文档。将时间线和整改负责人整理在整洁的 Markdown 表格中。最后附上一份验证清单，详细列出必须审查的遥测告警与代码审查规范。
## What to avoid
避免给出诸如“人为错误”等肤浅结论，避免做出关于零停机时间的无依据断言，切勿遗漏导致连接池故障的具体数据库查询机制。
## Success criteria
技术负责人阅读该文档后，能够清晰解释准确的故障机制，核实回滚恢复服务的原因，并分配具体的预防性工作项。
## Clarifying questions
仅在关键架构信息缺失时，提出最多三个针对性的问题。否则，请直接根据场景事实展开分析，陈述你的工作假设，并概述确认修复方案所需的遥测检查项。
为何有效
- 该场景为模型提供了具体的技术故障机制，避免其默认套用通用的服务器崩溃陈词滥调。
- 需求中强制要求输出标准的工程交付物，如 5 Whys 分析和精确的整改时间线。
- 约束条件防止模型臆造无关的基础设施缺陷或缺失的指标数据。
- 成功标准确保生成的报告可立即供技术负责人审阅并付诸行动。
定制你的提示词
使用 PromptDeck 构建专属版本：将文中的虚构场景替换为你自己的故障遥测数据、时间戳和架构技术栈。保留验证清单部分，以确保预防性工程任务能够得到严格审计。