1. 一个具体问题
网站故障后重启服务就恢复了，值班记录写着“内存不足，已重启”。两周后再次故障，说明恢复措施解决了当时症状，却没有解释内存为什么持续增长、为什么告警未提前触发，以及为什么系统无法隔离影响。
2. 一句话解释
根因分析通过事件、数据和机制检验追查问题形成条件，把临时恢复与预防复发分开，找到有证据支持的干预位置。
3. 出处与原意
Root Cause Analysis 是一组方法的统称，应用于质量、安全、可靠性和服务管理，ASQ 介绍了其调查与纠正行动用途。五个为什么、鱼骨图和时间线都可以成为工具，但没有任何一种工具保证找出唯一终极原因；复杂事件往往由多个因素共同形成。
4. 原理与机制
先保护现场证据并控制损害，再定义事件边界和影响，重建时间线。区分触发事件、潜在条件、失效屏障和扩大影响的因素。一个解释应与已知事实一致，也应能说明为何某些相似情形未出问题。选择对策后，需要用测试、监控或后续观察验证机制确实改变。把原因写成“人为失误”通常太粗，因为它没有解释什么条件让失误能够穿过防线。
分析还应保留无法确认的部分，区分高置信结论与合理猜测。找不到完整原因时仍可实施能够降低后果的防护，但应说明它解决的是韧性或探测问题。不能因为措施奏效，就倒推最初的原因猜想必然正确。
5. 一个完整案例
以下是假设案例。团队调查一次上传服务故障，日志显示大文件请求增加后内存持续攀升，重启可恢复。复现发现程序把整个文件读入内存，并发上传时峰值超过容器限制。进一步检查发现负载测试只用小文件，监控只看平均内存，且上传与其他接口共用实例。团队分别采取流式处理、大小限制、峰值告警和服务隔离。随后模拟大文件并发、异常中断与重试，观察内存上界和其他接口延迟。报告将“流量增长”记为触发条件，将缓冲策略和测试缺口记为机制及防线问题，而不是简单归结为用户上传太多。
6. 适用条件与反例
适合重复问题、重大异常和需要形成长期改进的事件。调查深度应与风险和可行动性相称，不能无限追溯到社会或文化层面就宣布深入。反例是把原因定为“团队缺乏质量意识”，提出一次培训，却不检查测试和部署条件；解释难以证伪，对策也无法验证。
7. 今天可以尝试的行动
为最近一次问题整理五个关键时间点，列出每个判断对应的证据。对最有把握的原因提出反问：如果它不存在，问题还可能发生吗？据此设计一次低风险复现或对照检查，再为长期行动写清验证方法与关闭条件。