一般事故发生，通常是几个质量卡点做的不到位，出现的事故往往也不会是很复杂的场景，一般先分析以下几种情况

研发侧：
1.是否是需求设计不到位，未考虑但是常用的情况
2.开发设计遗漏需求定义了但是开发遗漏了
3.测试设计用例场景的时候遗漏了
4.测试执行时遗漏未按用例要求严格执行
5.用例本身写的有歧义，误导了执行人

运维上线侧：
1.上线是否在非工作时间
2.上线操作是否符合规范
3.是否存在灰度机制
4.制定好的流程是否准确执行

个人经验，一般会逐级分类：

先按责任方分，主责事故（自己系统导致的问题）、非主责事故（其他系统出问题，连带影响到。比如机房网络挂了）
然后主责里面再分，具体的类型，比如代码问题、配置问题、数据问题、人为操作问题
根据具体类型，可以再进一步细分，比如代码问题，再细分为实现遗漏、实现不正确、健壮性不足等

一般统计分析，分到第二层就差不多了，到达这一层就足够去定一些比较通用的改进项，预防高频发生的事故。

测试环境和生产环境的不同，比如硬件配置、网络环境、第三方服务依赖等，可能导致在测试中没有暴露的问题在生产环境中出现。另外，测试覆盖不可能 100%，特别是边界条件、极端情况或者用户的不寻常操作路径可能未被覆盖到。还有可能是测试用例设计不够全面，或者测试时某些场景被遗漏了。此外，上线过程中可能出现的部署错误、配置问题，或者数据迁移的问题，也可能导致 BUG。还有可能存在回归测试不足，新功能影响了旧功能，但未被及时检测到。

参考 FMEA：https://zhuanlan.zhihu.com/p/523384133

都是测试的锅，把锅背好就行啦

简单点儿，原因就一种：某一个（些）人犯了错误，以程序的形式写进了产品以及运行的环境里了。