前言

这篇是个非常general的议题，关於从错误中学习，适合所有的工程师看。如果你常遇到工作上把意外怪罪为人为失误的话，特别可以看看，对於这些人为失误的意外，我们如何从中学习。

P.S. 这篇所有的演讲资料都可以从讲者的github上找到：learning from incidents

演讲总结

演讲想探讨的问题是：我们如何从意外事故（incident）中学习？与从意外中学习的正确姿势。

为何要从意外中学习？

简单的回答是：「因为我们想避免意外发生。」但我们真的有办法100%避免意外吗？

讲者表示「对於我们使用的复杂系统们，没有100%不会出错的」。原因是因为系统的运作永远都与人为操作有关，没有系统是不需要人为介入的。与其说人在操作系统（on system），不如说人其实是系统的一部分（in system）。

所以重点其实不在於避免所有意外发生，更多是我们要衡量灾难本身带来的影响，与我们是否能够承担灾难带来的後果。在公司里常常会有的状况是，我们花了很大的心力去避免意外产生，但是却导致我们操作越来越复杂或越来越难管理。

常见谬误

上面说了因为人是系统的一部分，所以人所用的语言去描述意外本身，也会大幅影响我们对意外的看法，进而影响我们能从意外中学到的事情。

所以下面列出四个常见的意外检讨的谬误：

1. 归因於人为操作失误（Attribution to "human error"）

   「人为操作失误」往往是个标签，让我们停止研究意外，因为大家会想说既然是人为操作失误那就无法避免了。

   但事实是，人当然会犯错，但系统设计、组织、个人因素与天时地利都有可能影响到人犯错。所以往往在意外发生当下，人不会觉得自己是犯错的。

   所以当我们听到「人为操作失误」，我们更应该深入探讨问题而非就此打住。

2. 反事实的讨论（Counterfactual reasoning）

   人们往往会在讨论中出现类似这样的言论：「如果当初...那应该就可以避免问题」「...没有做...所以...」。但讨论「没发生的事情」无法真正解决问题，我们应该聚焦在「发生的事实」上。

   所以你不该说「这bug没在testing中侦测到」，而应该说「这个bug要怎麽样才能在testing中被侦测到？」

3. 标准的语言（Normative language）

   事後诸葛总是最容易的，我们往往会从结果来看当初应该做的最佳决定为何，但是当你是做决定的人时，你哪知道哪个是最佳决定= =。

   所以我们其实应该多问决策者，事发当下有哪些现象与环境来帮助他做出这个决定。

4. 机械问题的讨论（Mechanistic reasoning）

   我们在寻找系统问题时，往往会去找到底是哪个元件（component）有问题。一旦发现没有component有问题我们就停止寻找问题了。但了解元件的问题不足以了解意外的全貌。

面对意外该如何学习？

接下来要讲讲如何从意外中学习，此处的细节可以从作者的github repo看到。

这里是站在一个协调者（facilitator）的角度来看这件事，而不是管理者的角度。而这个协调者不能是利益关系人，才能保持中立。（这里有个Debriefing Facilitation Guide，可以参考如何当个好的协调者。）

1. 事後检讨（post-incident review）

   我们常常叫意外处理者或负责人自己写incident report，但这其实这是不足的。

   最好是举办一个一个小时左右的post-incident review，大家一起来还原事件发生当下的状况。记住，重点不是要找出「正确的作法」而是还原当下情境。

2. 问正确的问题

   不要问why而是问how，因为问Why会让别人觉得被究责。而每个事件参与者对事件都有不同的体验，专注於理解这些体验与分享经验，而非决定哪些是「正确的」。

3. 询问事情要如何才不会出错

   当蒐集完与理解既有的事实之後，尝试去想需要哪些迹象、工具、技巧是可以帮助人做好决定的。因为做出不恰当的决策通常是因为资讯量不足，所以协调者的工作就是要找出中间资讯量的差异，并看用哪些方式可以弥补中间的隔阂。

4. 分开Review与Planning会议

   Review指的是事件回顾，而Planning指的是讨论下一步与修正错误的讨论。

   一方面是两者的目标不同，所以可以让两个会议分别专注在How与Next step上。也有更多时间可以沈淀找出更好的改进方向。

   而Planning的会议就就不需要牵扯太多人，可以尽量的短跟快速就好。

   另外Review会议最好是不要manager来参加，因为可能会害意外负责人噤声。而Planning会议就是manager可以参加的。

讲者也说到，当然做这件事情的成本蛮高，大家不见得会愿意花时间在这件事上面。因此可以先从找那些有趣，且不那麽重大的意外中开始练习做起，等大家对这个方式建立自信之後再慢慢的rollout出去。

个人心得

在听这篇演讲的时候，我完全就想到电影《萨利机长：哈德逊奇蹟》的情节。故事中主角机师Sully驾驶的飞机因为引擎故障，而导致他必须迫降飞机在河上，虽然被喻为英雄的拯救了所有乘客，但也被调查人员指责说做了不恰当的决定。调查委员会认为整件事是机师的疏失，因为他当下有更好的选择可以迫降在另一个机场，并且就模拟结果来说也是办得到的。但Sully表示那是不切实际的，因为模拟人员是在已知要如何反应的状况下操作，但对他来说却是要花时间来回检查与做出决定才能得出当下的结论。

整个故事俨然就是这篇演讲的精随：我们不该用结果去反推当下要做什麽决定才是正确的，因为往往当事者在做决定的时候是没有足够的讯息的。与其事後诸葛给出「最佳解答」，不如去还原现场与思考从资讯不足的情况如何找到解答，才会真正的获得进步。

预防问题的成本效益

另外演讲里有提到：我们往往会为了阻止某个问题的发生，而复杂化我们的流程。并不是说不该阻止问题发生，更重要的是我们要去评估「我们在阻止问题发生上所需要花费的精力」与「事情真的发生要修正他花费的精力」是不是成比例的。

之前就有过Ops（operators）因为不太信任我们的系统，所以提出需求希望我们多产一两个report来让他们做交叉比对资料正确性。可以理解他们的初衷，但是产report的effort其实很大，加上又会多一件事要来maintain，对他们来说也需要多出人力来检查，更重要的是，产生report的部份基本上一年来也没有坏过...，如果真的要做那就是为了做而做的而已。这就是「花费力气避免问题产生」的效益与「出问题的影响」不成比例。

追根究柢真的好吗？

虽然这篇演讲是在讲述追根究柢的必要性，但我并不认同所有事情都必须要找到root cause。原因是因为资源是有限，无论是人或时间或精力都是。

相信各位工程师们都有惨痛debug经验，大部分时候写feature其实不难，难的是debug或找出问题所在。很多时候我们寻找问题的root cause所花费的时间已经远远大於问题产生的可能性了，那我们还应该继续查下去吗？例如说每个月会有十几个订单会有奇怪的行为发生，而我已经花了两天的时间寻找了各式各样的log跟看了code但是都找不到问题，是否还有必要继续花时间下去？

我自己觉得这一切都跟资源分配与成本效益有关，你花月多的时间在这个bug上你的边际效益就越低。当然如果是个严重的问题绝对是必须要查出来的，但是大部分状况下问题其实并不是那麽的严重，所以要谨慎考虑是否要继续投资时间下去查出问题根源。

批判性思考与意外的全局性

演讲也提到：知道出问题的元件在哪并不代表你知道意外的全貌。

在公司里之前就会出现一些奇葩的状况是，线上有个bug，而我们为了快速修正所以生了一个report来去让OPs（operators）去手动修正这些数字。相安无事过了一阵子後，某天你接到一个request说这个report没考虑到某个状况要把特殊状况考虑进来。来来回回几次之後发现原本只是workaround（=暂时解决某个问题的应变方法）的report，却变成正式的report了，OPs还甚至多花了个人力去做这件事。但实际上应该要做的是：修正原本的bug阿RRRR，如果没有这个bug的话根本就不用这些report了。

我们花了一堆心力去东补西补某个系统会产生的毛病，但是却没想过本身这个系统的设计就是造成这些问题的根本。所以窃记不要看到一点病徵就尝试解决他，确认已经了解事情的全貌再去讨论下一步。