软件质量工程之COE

前言

1.1 背景

服务可靠性至关重要，服务不可用会导致极差的用户体验、可能引起资金损失，用户流失，从而降低客户信任度和商业价值。当然故障可以说是不可避免的发生，一个标准的事件复盘机制可以让我们可以在事件发生后对故障进行充分的分析，避免再次发生同样的事故。而且一个标准的事后复盘机制还可以帮助我们更多地了解我们的系统是如何工作的，进而提前发现还未暴露出来的潜在风险。COE(Correction Of Error)正是一个标准的事件复盘机制，源自亚马逊，是该公司作为质量工程的重要工具，本文浅略介绍COE的原理及实践方法。

1.2 读完本文你可以获得什么？

本文的目标读者是具有一定软件工程背景的软件开发工程师、软件工程管理人员、项目管理人员以及信息技术行业的从业者。读完本文你将对COE流程有个大致的了解，理解它是什么，为什么需要它，什么时候使用它，如何使用它。在日常工作中可以使用本文所提供的COE模板对问题复盘进行标准化分析、总结、沉淀及输出。

COE介绍

2.1 What: COE是什么？

• 2.1.1 标准化文档&流程

COE(Correction Of Error)是一种通过记录和处理问题来提升软件工程质量的流程。所谓记录问题就是通过标准化的文档来记录造成问题的根本原因，这一部分也叫根本原因分析(Root Cause Analysis)；所谓处理问题，就是通过标准化的流程来逐一消除造成问题的根本原因，从根本上解决问题。需要指出的是，COE即是一种文档的类型，也是一种流程。我们可以理解COE是一种“复盘”。复盘，围棋术语，指对局结束后，双方旗手把刚才的对局再复演一遍，这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法。当一个人精通复盘之后，他对于自己的工作就会有深刻的认识和体悟，具有一种惊人的直觉。就可以从纷繁复杂的现象中一眼抓住关键所在，找出解决问题的方法和路径。下表我们直奔主题，看看一个COE文档是如何构成的：

2.1.2 COE不是什么？

COE不是找出谁应该为问题负责的过程：COE 的目的是促进优化和改进，这需要创造一种鼓励解决问题的文化而不只是问责的文化。

COE不是在发生事件后对员工进行惩罚的过程：很多时候，对一件事了解最多的人往往是其结果最有风险的人。为了激励对事件过程的最完整的理解，我们必须创造一种文化，奖励对事件的全面披露，否则这个对故障最为了解的COE文档编写者势必对了解的情况遮遮掩掩，以尽可能规避对自己不利的因素。

COE不是绩效管理工具：在某一家公司工作的时候，一个影响绩效的指标就是背了几个COE，即“COE==大故障”，大致有个COE就背差绩效，这家猛学亚马逊的公司，渐渐将一个软件质量工程管理的工具变为一个处理人的工具。

2.2 When:什么时候用COE?
我认为需要进行COE的故障应该具有代表性：当前影响面较大的问题，流程规范性的问题，管理上的问题，暴露潜在大风险的问题。

2.3 Why:为什么要用COE？

• 2.3.1 标准化文档的好处

COE不仅对根本原因分析进行书面记录，同时以规范的格式进行书面记录。规范的格式也有至少有以下两个好处：便于阅读，和提取关键信息：想象一下，如果你从100篇错误分析文档中找出一共有多少文档是部门A发布的，一种情况是100篇文档格式不尽相同，发布部门信息散落各数，另一种情况是格式一致，发布部门信息都在前言里。必然是格式一致的文档能方便你提取你需要的关键信息—故障周期、影响面、原因、action等。便于自动化提取关键指标：文档规范化后，可以交由软件自动读取，分析出关键指标。比如从1000篇COE中发现123篇的根本原因都是X，那么管理层可以得知解决X的重要性，并且可以用这些指标来进行科学决策。

• 2.3.2 标准化流程的好处

COE将根本原因分析的流程标准化，帮助我们快速，准确地深入研究导致事件发生的时序，找到问题的根本原因并确定补救措施，分析事件对业务和客户的影响，进而找出问题的根本原因。不仅如此，COE作为标准化的文档，可以帮助相关团队高效的Review，也可以帮助其他团队快速的提取出关键信息来学习。此外，由于文档使标准化的，公司可以通过统计方法得到丰富的指标，比如有多少错误的根本原因是由于“证书过期”引起的，进而能够作为预防故障发生的资料。

2.4 Who:谁来写COE？

在软件系统错误发生时，一般由当事人起草COE。当事人可以是导致错误发生的软件开发工程师，可以是在代码审核过程中遗漏该错误的工程师，也可以是该软件系统的负责人。选择他们是因为他们对出错误的系统最为熟悉。在亚马逊的企业文化里，由某一个人导致的软件系统错误也可能同样发生在其他任何人上，所以要改善流程而不是批评指责某个具体的人。

案例分析

• 3.1 随便举的一个例子