选工作前，先了解该公司怎么做事故检讨

今晚在写 E+ 的主题文时，看一些资料看到 AWS S3 在 2017 年有个重大事故，导致损失超过 1.5 亿美元，而该重大事故的原因是来自打错字 (typo)。

多数人看到这，可能第一时间想 AWS 这么大一间公司，怎么会犯「打错字」这种低级错误? 过程中没有检查机制吗? 出问题怎么会直接影响全球，没有先金丝雀部署吗?

当年我造成的事故

但我看到这个事件的历史资料时，第一个想到的是我在前公司造成的一个事故，虽然不是因为打错字，但因为处理某个配置的资料格式有误，导致数十个模组在生产环境直接被影响到。

那时我被拉进一个线上会议，里面有各地办公室加起来快五十个工程师，因为他们负责的东西都被影响到。

好在前公司在部署回滚的整体配套很完整，整个事故不到十分钟被回滚解决，但是突然被拉进那么多人的会议，然后发现自己竟然是搞出事故的人，那种头脑一片白、全身起鸡皮疙瘩的感觉，至今想忘都忘不掉。

然而，如同所有事故，缓解事故本身重要，但事故后的检讨更重要。更进一步说，如何检讨事故又更加重要。

不指责人的事故检讨很重要

记得当时的主管跟我说，不要担心，就把这当一个学习经验，然后确保未来同样的问题不会再发生。

在那之前我其实已经读过不指责人的事故检讨 (blameless postmortem) 的概念，只是当自己成为造成事故的事主后，才更加意识到这种做法的重要性。

那次的事故检讨后，做了许多实际的调整。这让我在看 S3 2017 年事故的检讨时，觉得特别熟悉，因为他们检讨后做出的改进，几乎跟我当年造成的事故后的具体调整很相似。

除了最基本在配置档案加上格式校验的逻辑外，原本只有程式码部署强制走金丝雀 (canary)，后来配置也加上强制金丝雀，然后直接把监控面板跟金丝雀部署的流水线 (pipeline) 串一起，每个配置部署时都确保有完整监控。以及当事故发生时，根据监控的设定，在侦测事故时把部署自动回滚 (rollback)。

因为加上这些机制，在未来同样的低级错误，变得不可能发生。这类从工程的角度来避免人为错误的可能性，是事故检讨的价值所在。

面试时记得问对方如何做事故检讨

因为那次经验，后来找工作时，在面试阶段的提问时间，我一定会问面试官如何做事故检讨。因为确保是用不指责人、专注在改善的方式，才会是我会想去的团队。

这世界没有完美的人，也没有完美的流程，犯错总是难免的，只是如果同样的错误再犯就不应该；因此团队该关注的，不是谁犯错，而是如何让未来不会再犯同样的错。

当一个组织文化演变成找战犯、指责人的情况，当问题发生时，犯错的那个人或团队，很可能会试图掩盖问题 (因为不想被指责或背锅)，这对于解决问题反而是不利的。这也是为什么多数有良好文化的组织，会强调在出事故时不指责人，而是专注在针对事。

如果你对这个主题感兴趣，或者对于成为资深工程师该具备哪些软硬实力感兴趣，欢迎加入我参与制作内容的 E+ 成长计划，在 E+ 里面当中有更深度的内容，E+ 的介绍可以在这个 连结 看到。