Correction of Error (COE)

文章目录

前言

本文写作的原因

亚马逊作为一家科技公司,在软件工程上有许多值得借鉴学习的地方。其中COE作为质量管理的重要一环,十分独特。本文浅略介绍COE的实践方法,所有参考文献均来自互联网公开资料。

目标读者

COE属于软件工程领域中,质量管理流程中的错误管理。所以本文的目标读者是具有一定软件工程背景的软件开发工程师,软件工程管理人员,项目管理人员以及信息技术行业的从业者。

读完本文你将获得什么?

读完本文你将对COE流程有个大致的了解,理解为什么需要它,什么时候使用它,以及使用COE流程的好处。

正文

什么是COE?

COE[1]是一种通过记录和处理问题来提升软件工程质量的流程[2]。所谓记录问题就是通过标准化的文档来记录造成问题的根本原因,这一部分也叫根本原因分析[3];所谓处理问题,就是通过标准化的流程来逐一消除造成问题的根本原因,顺藤摸瓜,釜底抽薪,从根本上解决问题。

需要指出的是,COE即是一种流程,也是一种文档的类型。在没有特指的情况下,需要根据上下文来判断其具体含义。

什么时候需要COE?

COE一般用来对错误进行书面分析,然后留档保存。对于公司业务影响较小的问题,根本原因分析起来一般来说比较简单,不需要书面分析。即便根本原因分析起来复杂,因为对业务影响小,分析也没什么价值。而对公司业务影响较大的问题,则需要书面分析。书面分析至少有以下两个好处:

  1. 对公司业务影响较大的问题,通常造成问题的因果关系复杂,书面记录有助于当事人顺藤摸瓜,分析问题。
  2. 好记性不如烂笔头,书面记录不仅令当事人印象深刻,更重要的是,书面记录便于留档保存,可以供他人查阅和学习。

如何定义业务影响的大小?

业务影响的定义对于不同行业的公司,对于不同大小的公司都是不同的。比如对于一家提供视频网站的公司,如果有10%的用户无法观看视频的插片广告,那么这是一个对业务影响较大的问题。如果有1个用户无法观看视频的插片广告,那么这是一个对业务影响较小的问题。此时可以根据公司的体量,设计双重指标,如果有超过x%的用户,或者超过y个用户无法观看视频的插片广告,那么这就是一个对对业务影响较大的问题。

COE的好处

COE不仅对根本原因分析进行书面记录,同时以规范的格式进行书面记录。规范的格式也有至少有以下两个好处:

  1. 便于阅读,和提取关键信息:想象一下,如果你的直属领导要求你从100篇错误分析文档中找出一共有多少文档是部门A发布的,一种情况是100篇文档格式不尽相同,发布部门信息散落各数,另一种情况是格式一致,发布部门信息都在前言里。必然是格式一致的文档能方便你提取你需要的关键信息。

  2. 便于自动化提取关键指标:文档规范化后,可以交由软件自动读取,分析出关键指标。比如从1000篇COE中发现123篇的根本原因都是X,那么管理层可以得知解决X的重要性,并且可以用这些指标来进行科学决策。

举个例子

其实根本原因分析普遍存在于软件工程的生产实践中,根据问题的影响范围,软件工程师会采用合适的方法来分析问题,以在电商工作的张三为例

No 问题类型 问题造成的后果 问题的影响范围 问题对公司造成的损失 如何应对问题
1 张三电脑系统出现问题,没法开机 张三工作进度收到影响 张三一个人 微小 当天找IT部门修复电脑
2 张三的公司内部聊天系统出现问题,员工没办法新增好友 使用该内部聊天软件的员工没法加新的好友 公司内部员工 有一定影响 在几天的时间内紧急修复问题,或者回滚造成错误的代码
3 张三的公司网站用户购物车出现问题,没法把商品放入购物车 用户没法购物 100%的用户 重大影响,生意没法做了 在几分钟的时间内紧急修复问题,或者回滚造成错误的代码

对于第一个例子,问题的影响的范围小,解决问题的方法也直截了当。根本原因分析心算即可完成,此时没有必要进行书面的根本原因分析。

对于第二个例子,问题有一定的影响范围,而且不注意的话,错误有可能再次发生,为了避免类似的错误,应该进行书面的根本原因分析,记录问题的根本原因,并且在紧急修复问题后,应该提出避免类似错误的措施,并且和相关团队讨论,审核,施行该措施。

对于第三个例子,问题的影响范围重大,不但要进行书面的根本原因分析。错误分析还要印发给各个部门,组织全公司的各个团队从错误中学习经验。

对于第二个和第三个例子,COE可以标准化根本原因分析的流程,帮助张三快速,准确地分析出问题的根本原因。不仅如此,COE作为标准化的文档,可以帮助相关团队高效的审核,也可以帮助其他团队快速的提取出关键信息来学习。此外,由于文档使标准化的,张三的公司可以通过统计方法得到丰富的指标,比如有多少错误的根本原因是由于“证书过期”引起的,还有张三坐在部门一年的COE数量相比去年的变化,是多了还是少了。有了这些指标,项目经理和领导层可以根据数据来做出决策。

谁来写COE?

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

COE编写完后,相关团队会一起开诚布公的审核COE文档,不仅审核根本问题分析,而且要审核为了消除根本问题所制定的纠正措施[4]。有些纠正措施致力解决眼前的问题,比如紧急修复一个错误。有些纠正措施则目标长远,目的是改善相关流程。解决短期和长期的纠正措施所需要的时间不同,所以纠正措施的预计交付日期也不尽相同,审核也包括评估纠正措施的预计交付日期。比如预计的交付日期是否合理。

杂谈

COE是软件开发工程师的"检讨书"吗?

COE的终极目标是避免重蹈覆辙,而不是把错误归咎于某个人,因此对造成错误的软件开发工程师不会,也不应该有任何的责罚。COE不是软件开发工程师的"检讨书",而是软件开发工程师对抗来自项目经理不合理要求的“武器”,同时也是保护软件工程师的“防弹衣”。

在COE审核结束后,COE里的纠正措施通常比实现软件的某个新功能有更高的优先级,如果此时有项目经理提出与COE相悖的优先级排期,比如得把COE的纠正措施搁置一旁去实现某个新功能。此时软件开发工程师可以援引COE的纠正措施来质疑不合理的要求。

如果领导介入,得把COE的纠正措施搁置一旁。那么领导就需要承担COE中错误再次发生的后果。

起草COE的软件开发工程师会感到内疚吗?

一般来说,起草COE的作者是对出错误的系统最为熟悉的工程师,并不一定是直接导致问题发生的工程师。就算是直接导致问题的工程师,他或许会对造成问题心存内疚,但是写COE却不会。不仅如此,写COE也是工程师的某种“荣誉”。软件系统不可能不出错,世界上最稳定的服务也无法达到100%的可用性[5]。但是一篇一篇的COE,是亚马逊工程师们学习的源泉,成年累月地从错误中汲取经验,使得亚马逊服务的稳定性能向99.9%的小数点后再增加一位。

附录

COE模板

以下模板所有内容纯属杜撰,如有雷同,请勿对号入座。

错误简述

简述错误,并配以时间线

2007年1月1日,时间下午14:00,公司A电商网站预计举行抽奖活动B。当日下午13:00。负责为抽奖活动提供技术支持的团队C的某软件工程师(注意不要出现姓名)发现一个会妨碍抽奖活动的bug,在巨大的时间压力下,修复该bug的代码未经测试便直接上线。导致公司网站的购物车功能从14:00瘫痪,直到14:30,该问题才由运营技术团队D发现并紧急回滚包含错误的代码。

  • 2007-1-1 13:00:00 (CST) 团队C的某软件工程师发现了一个会妨碍抽奖活动的bug。
  • 2007-1-1 13:15:00 (CST) 该软件工程师把码未经测试修复代码直接部署到生产环境中。
  • 2007-1-1 14:00:00 (CST) 电商网站的购物车功能开始瘫痪,用户无法把商品放入购物车中。
  • 2007-1-1 14:30:00 (CST) 运营技术团队D,通过每秒放入购物车物品件数指标的断崖式下跌发现购物车异常问题。
  • 2007-1-1 14:45:00 (CST) 运营技术团队D通过紧急回滚包含错误的代码恢复了购物车功能,网站购物车功能自此正常工作。

错误影响

错误对于用户,业务造成的影响,最好列举相关的指标

该错误导致抽奖活动B取消,此外,由于购物车功能收到影响,45分钟内,网站的所有用户均无法把商品放入购物车中。根据历史数据,此时用户数量为X,活动B预计增加Q%的客流量,购物车转化率为Y%,平均每单收入为W元人民币。这次事故对于公司A的收益影响是

1
X*(1+Q/100)*Y*W 元

根本原因分析

刨根问底,顺藤摸瓜,造成错误的最根本原因是什么

  1. 为什么公司A购物车功能瘫痪了?
    因为团队C的工程师把码未经测试修复代码直接部署到生产环境中
  2. 为什么团队C的工程师把码未经测试修复代码直接部署到生产环境中?
    为了紧急修复会妨碍抽奖活动的bug
  3. 为什么修复妨碍抽奖活动的bug会影响网站A购物车功能?
    因为抽奖活动代码和购物车功能代码过于耦合
  4. 为什么抽奖活动B代码和购物车功能代码过于耦合?
    因为负责购物车功能的团队E没有提供相应的API,抽奖活动B的功能代码直接在购物车功能中实现了。
  5. 为什么要购物车功能中实现抽奖活动B的功能,为何不先重构购物车功能并且先实现API?
    因为抽奖活动B过于紧急,需要在2007-1-1上线。

反省经验

吃一堑长一智,从错误中学习到的宝贵经验

  1. 要进行合理的项目排期,不能因小失大。技术团队要及时向上级反映情况,不能因为满足眼前的功能而放弃项目的长期规划。
  2. 各个技术团队负责的产品要通过API定义的合同进行沟通,不能瞎耦合代码。
  3. 紧急修复也要有相关流程,至少要通过同行代码评审和自动化测试。

纠正措施

为了避免重蹈覆辙,都有那些短期或者长期的纠正措施

  1. 短期措施: 修复妨碍抽奖活动B的bug,对于抽奖活动重新排期。预计新的抽奖活动B时间:2007-1-7
  2. 短期措施: 出台紧急修复流程,紧急修复至少需要通过同行代码评审和自动化测试。
  3. 中期措施: 对购物车功能进行重构,向抽奖活动B的技术团队提供API,通过API解耦。预计完成时间:2007-2-1
  4. 长期措施: 团队B和团队E负责审核他们项目中的所有代码,通过API逐步解耦其他地方的不合理耦合。预计完成时间:2008-1-1

COE流程总结

对外公开的COE

对外公开的COE其格式有所变化,其侧重点在于错误分析,但是也可以看到具体的纠正措施

  1. 2020年11月25日,最近一次,发生于US-EAST-1地区的Amazon Kinesis Event事故总结
  2. 2017年2月28日,使Quora,Trello等网站停运数小时的著名的Amazon S3事故总结
  3. 2012年12月24日,发生于圣诞节前夜,把Netflix也拉下水的Amazon ELB事故总结

参考文献

  1. AWS Well-Architected Framework > Concepts> Correction of Error

脚注


  1. COE:Correction Of Error,也即纠正错误。 ↩︎

  2. 流程:软件工程流程的简称。流程,就是为了完成某一目标而进行的一系列,有序的步骤。就如同生活中,为了做菜这个目标,流程可以是就是先买菜,然后洗菜,最后炒菜。 ↩︎

  3. 根本原因分析:Root Cause Analysis。顾名思义,沿着因果关系组成的链条,找到问题的根本原因。来源自管理学概念,详情参见https://en.wikipedia.org/wiki/Root_cause_analysis ↩︎

  4. 纠正措施: Corrective Action的直译。 ↩︎

  5. 可用性:Availability。简单的说,可用性就是一个系统处在可工作状态的时间的比例。例如,服务A在一年时间里(8760小时)有8751小时可用。其可用性则为8751/8760 = 0.999,或以百分比表示99.9%。详情参见https://en.wikipedia.org/wiki/Availability ↩︎