如何看待亚马逊的错误更正（COE）流程？是批斗？还是甩锅？软件工程师怎么说……

关注我，每天收获一个新技能!

今天，我和一位朋友进行了一次有趣的对话，谈论了当发生影响客户的重大问题时，亚马逊的错误更正 (COE) 流程（如果您不熟悉它，可以在此处阅读有关亚马逊 COE 程序的更多信息）。

简而言之，COE 是工程师在发生影响客户的 bug 事件后编写的详尽文档，详细说明了问题发生的原因以及如何在未来防止此类事件发生。那么，这个流程和流程产生的文档是否真的对组织进步有正向作用？还是它会破坏组织文化，形成甩锅，指责，甚至批斗文化？

在国内公司里，对于COE的反馈，我真实听到的更多是负面反馈。绝大多数工程师把它看成“某角色（人）的批斗会”。所以，我也产生了好奇心。

想听听Amazon 工程师对这个事情的反馈。于是，我就搜索了一下。

就上下文而言，我们都是亚马逊的 SDE。

（正方）我认为COE对公司（即我的同事和其他团队）和我自己（作为一名有抱负的工程师）写一份 COE 非常有价值。

（反方）我的朋友则认为这是一个官僚程序，与常规的随叫随到的 Sev-2 问题相比，它没有任何额外的价值，虽然 Sev-2 问题也可以得到缓解，但不需要像 COE 那样进行广泛的程序、文档和审查。在他看来，COE 毫无意义，因为它通常由高级工程师和业务/产品团队口述和审查，但一个月或一年后实际上没有人会阅读，从而导致问题再次发生。

例如，如果今天编写了一份 COE，明天或一年后的新毕业生将无法看到它，并且会遇到相同的问题。与也存在影响客户的问题的常规 Sev-2 相比，COE 还可以缓解问题并防止再次发生，而无需编写一份长篇文档并与领导层进行数天的审查。

我认为：当然没有人喜欢犯错，因为COE的确是一个痛苦而烦人的过程。我完全同意，作为一名 SDE，我最不想做的事情就是编写 COE。但我认为编写 COE 非常重要，可以真正防止这种情况再次发生。这与其说是为了缓解或解决问题本身（因为无论如何这都是必需的），不如说是为了理解问题并解决实施护栏并防止再次发生的行动项目。

在我的朋友群中，对于”他们是否认为编写 COE 很有价值“这个问题，我收到了各种各样的回复。

然而，我还想听听其他 SDE/SWE 的意见：

（1）当他们的服务发生重大问题时，他们是否认为编写 COE 有真正的好处？

（2）你认为在公司采用这样的流程从长远来看是否真的有帮助？这是一个可持续且有价值的流程吗？还是它只会让 SDE 和相关利益相关者因不相关的官僚程序而疲惫不堪？您是否支持 COE？

回复1（支持）：

即使所有相关人员都被新员工取代，正确编写的 COE 也能防止问题再次发生。

COE 的部分目的是找出事件的根本原因，但更重要的一点是查看根本原因并找出如何预防它。

写得不好的 COE 可能会被总结为：“此次中断是由于一名工程师意外删除了生产数据库表而导致的。我们添加了一些文档来警告其他人不要这样做。”

更好的 COE 不会将工程师错误作为根本原因。工程师如何能够删除生产表？缺少哪些可以防止这种情况发生的检查？这可能会导致需要第二方或第三方批准才能进行更改。更好，但我们还没有做到这一点。

更好的 COE 不仅会考虑如何允许修改生产数据库，还会考虑为什么有人认为这是正确的操作。我们是否缺少可以消除这种手动操作的工具或自动化？是否有一个应该用自动化取代的流程？缺少什么导致首先需要手动操作？

一旦确定了正确的根本原因，下一个关键部分就是行动项目。这些将被跟踪和跟进，如果未完成，则会升级。

最后是 COE 门槛提高的流程，由一位未参与事件的公正评估员检查报告并确定其是否充分解决了问题的根本原因，以及提议的行动项目是否足以防止事件再次发生。

COE 流程有很多令人不满意的地方，特别是当你是负责撰写报告的人时。但是如果你的朋友认为它无法有效防止再次发生，他们可能希望仔细查看 COE（行动项目）的实际输出，而不仅仅是报告本身。

来源：我在亚马逊担任了 15 年的 SDE，作为一名作者、利益相关者和审阅者，见过许多 COE。

回复2（支持）：

同意；我在亚马逊工作期间发现 COE 非常有用，无论是书写还是阅读。重要的是尊重围绕 COE 制定的流程。

当出现问题时，人们很容易会惊慌失措，然后疯狂地修复它，松一口气，回到工作岗位，而当有人说“我们需要写 COE”时，人们就会抱怨，觉得这件事已经结束了，让我们继续前进吧。

如果你真的想像所有大型科技公司那样“庆祝失败”，那么你必须建立一种机制，让失败为整个公司带来一些有价值的东西。否则失败就只是失败而已。

回复3（支持，用于在下次评估工作量时多加一点儿时间）：

我认为亚马逊做得非常好的一点是围绕行动项目的机制。一旦你为它分配了优先级，就会为你设定最晚完成日期。如果任务没有在那个时间范围内完成，管理层的人就会开始知道你的名字。所以我觉得这是一种非常有效的方法，让工程师重新确定 PM 可能想要推迟的技术债务的优先级。

回复4（支持，用于甩锅的好武器）：

它们确实有用...但我还看到它们被用作将责任推给其他团队的武器。

回复5（支持）：

我的公司也有类似的经验教训。这绝对是工程流程和产品改进的一部分。

您的朋友也说得对，如果不读文档，文档就毫无用处。

简而言之，问题不在于记录失败。问题在于流程存在缺陷。反馈回路其实已损坏。问题不在于文档，而在于利用收集的数据的过程。应该有人创建一份需要审查问题的最佳实践文档。然后团队应该遵循最佳实践。流程应该在新项目开始时纳入审查，以确保错误不会再次发生。

这些事情总是被视为官僚主义的垃圾，除非它能拯救你。

我还要指出，开发人员通常看不到这些类型缺陷的副作用。发生在客户层面的错误会导致声誉受损和销售损失。这通常只有高级工程师才能看到。因此，您的低级开发人员看不到任何好处，因为他们没有看到错误造成的后果。

回复6（支持，但是）：

我希望大多数公司都有类似的流程。但是，我想知道，在严重性问题/工单上进行类似的记录是否足够。我们的讨论并不是关于记录发生的问题（我们同意这些问题很重要），而是关于广泛的 COE 的正式流程。

不知道您的公司如何，但我们有定期的待命工单，我们会直接记录工单和问题的发现，并在回顾时与团队讨论。不同团队在如何采取最佳行动和处理这些问题方面有所不同。

COE 似乎是同一流程的精确复制品，但规模更大。审查和编写 COE 可能需要几天甚至几周的时间，并涉及团队以外的利益相关者，甚至可能是公司董事。同样，我仍然看到它的好处，因为它确保了标准化流程并保证工程师能够完成它，尽管这很烦人。但您是否认为，对此类问题进行如此广泛的、以业务和工程师为导向的记录是小题大做？

回复7（支持）：

不。这看起来工作量很大。但它确实可以帮你省去额外的工作。

这些流程的全部意义在于确保下次能够反馈到设计和架构中。是的，它应该包括所有利益相关者。我经常看到的是，利益相关者受到开发过程中发生的失误的严重影响。因此开发人员无法看到正在产生的所有问题。对他们来说，这没什么大不了的。对其他人来说，他们的错误是数周的返工。简而言之，很多开发人员是孤岛思维，而不是系统思维。

我不得不坐在那里向客户解释为什么当前项目不会像 x 项目那样搞砸。我们几乎因为开发人员的不忠而丢掉了合同。

回复8（支持）：

我在零售部门担任了一年半的 SDE，COE 流程是我在那里学到的最好的东西。在我的部门，它有点像学期论文，你需要花好几天时间才能写好，然后听听管理层的几次反馈。

最让我印象深刻的是，公司所有事情都采用相同的模板。我输入了随机的 COE 号码，只是为了看看会出现什么结果。我还记得有一次，一名清洁工将真空吸尘器插入服务器机架上的插座，跳闸，并关闭了部分线路。主要行动是盖上插座。他们显然在 30 分钟内完成了整个文档，对于大多数次严重事件来说，这似乎是合适的时间。

回复9（支持）：

你忽略了 COE 流程中最重要的部分之一 - 跟进行动项目，并设定团队需要遵守的具体截止日期。大多数公司都止步于此。事后分析（COE 的通用行业术语）很正常。

回复10（支持，但是）：

如果使用得当，它们非常有用

话虽如此，如果可以的话，我会避免填写

关注乔帮主的直播，让你少走弯路，事半功倍！

本期话题：老板要提升研发效能