每当一个系统上线开始运维以后，项目组就会进行到一个阶段，不断的收到从线上反馈回来的生产事件，对生产事件进行有效的深度挖掘、分析，形成正确的改进项，可以持续的完善系统和研发管理过程。
常用的缺陷分析方法有：根本原因缺陷分析法、四象限缺陷分析法、ODC 缺陷分析法、Rayleigh缺陷分析法和Gompertz 缺陷分析法。
ODC(Orthogonal Defect Classification，正交缺陷分类)是获取缺陷的一种分类方案，但它不仅仅是一个分类方案，还是一个软件过程的度量系统，它是建立在包含于缺陷流中的语义信息基础上的，可以帮助评估测试效率，对错误进行跟踪，通过方案的分析机制可以评估客户的满意度。
1990 年Ram Chillarege 博士等人提出ODC 概念，并于1997 年基本完成ODC 理论体系建设。1998 年以后，IBM 公司开始在其全球24 个研发机构推广该技术，并取得了很好的经济效益。
ODC 一共有8 个属性，如下图所示。
通常ODC缺陷分析法是在研发阶段，当测试工程师发现缺陷并进行提交时，可以为该缺陷分配“活动(Activity)”“触发(Trigger)”和“影响(Impact)”三个属性;开发工程师在修改缺陷时，可以为该缺陷分配“阶段(Age)”“来源(Source)”“限定符(Qualifier)”“类型(Type)”和“目标(Target)”五个属性。
而针对生产缺陷来说，处理流程一般为:
- 用户或者业务人员发现生产环境的问题，告知运维人员
- 运维人员判定是否为系统的缺陷
3.运维人员无法判定时，需要通知系统的开发团队协助判定是否为系统缺陷 - 若问题为系统缺陷，则转为生产缺陷，进入Hotfix流程或者下一个版本排期进行修复
结合ODC理论来说，我们可以在生产事件分析时采用对应的八个属性来做分析。
在分析生产事件产生的整个过程的阶段时，可应用的三个属性为Activity、Trigger、Impact
Activity：就是当生产事件发生时的处理步骤。比如部署数据库，应用发布等。
Trigger：描述了暴露缺陷时存在的环境或者条件。针对不同的 Activity，会对应有不同的 Trigger。
Impact：是指事件可能造成的影响，包括资金影响、用户影响、声誉影响等。
当对生产事件进行全面的复盘分析以后，基本可以定位在代码或者流程的某个地方进行完善，对于修改部分的分类有利于以后的流程改进和代码质量改善，此处可应用接下来的五个属性：Target、Type、Qualifier、Source、Age
Target：将要在哪里改正错误，例如：需求分析阶段、编码阶段、测试阶段、发布阶段 等等。
Type：表示所进行的实际修正的种类，比如算法，接口，初始化等等。针对不同的 Target，也会定义不同的 Type。
Qualifier：指明了所进行的修复应归于缺失，错误或者还是外来的代码或者信息。
Source：指明了发现的缺陷的来源，是出现在内部代码编写中，重用自一个程序库中，从一个平台转移到另一个平台上的，或者是外包一个软件销售商的。
Age：确定这个缺陷是新代码还是旧代码，或者是重写的代码。
ODC分析案例
比如在某一个金融系统中，出现了A账户的钱出现在B账户中，上线后用户爆出故障后，紧急处理，原因就是开发人在使用多线程时，将多例使用成单例，导致系统在高并发进出现了串数据的现象，导致系统在处理时放错款，将A的钱放到B的账户中去了。
用ODC的理论来分析一下上述的事件。
Activity：上线后用户进行转存帐的操作
Trigger：大于500个用户高并发的同时使用转存帐的操作
Impact：
- 资金影响：用户A的账户钱数目会减少，公司需要进行赔付
- 用户影响：用户对此金融系统易产生不安全感
- 声誉影响：金融系统出现账务错误是影响面很坏的事件，严重的时候甚至可能受到银监会的处罚
通过对代码的分析，知道是在开发人员使用多线程时，将多例使用成单例，所以出现的在高并发情况下会有串数据的现象。后续的修复措施可以总结为：
Target：需要在代码设计阶段针对这种会有多用户并发的业务场景中，明确在编码过程中需要用多例的方式。
Type：实际修正的种类为多线程的实现。
Qualifier：所进行的修复应归于代码错误。
Source：发现的缺陷的来源是出现在内部代码编写中。
Age：确定这个缺陷是新代码。
同时分析出来在编码中，虽然使用单例能节省资源，降低系统的占用率，但这种情况并不合适目前的系统。而此中情况在测试过程中并不一定能测试出来，这种出现的机率不定，必须在数据高并发时才有可能出现。
CC说：可以设想一下，如果在一段时间以内，对多个缺陷进行Target种类的分析，代码设计阶段占比较多的情况下，就需要对研发过程中的代码设计阶段进行很好的改善以此来提高之后的研发过程。