《敏捷开发艺术》第二版

事件分析

听众

整个团队

我们从失败中学习。

尽管您尽了最大努力，但您的软件有时还是会出现故障。有些故障很轻微，比如网页上的一个错别字。其他故障则更为严重，如代码损坏客户数据，或中断服务导致客户无法访问。

有些故障被称为错误或缺陷，有些则被称为事件。这种区分并不特别重要。不管怎样，一旦尘埃落定，一切恢复正常，你就需要弄清楚发生了什么，以及如何改进。这就是事件分析。

注意

如何在事故发生时做出响应的细节不在本书的讨论范围之内。有关事故响应的出色实用指南，请参阅《网站可靠性工程：谷歌如何运行生产系统》[Beyer2016]，尤其是第 12-14 章：谷歌如何运行生产系统 》[Beyer 2016]，尤其是第 12-14 章。

拥抱失败

Agile 团队深知失败在所难免。人们会犯错误；会出现沟通不畅；会有不成功的想法。

Agile 团队不是为了避免失败而孜孜以求，而是拥抱失败。如果失败不可避免，那么重要的是尽快发现失败；及早失败，因为还有时间恢复；控制失败，使后果最小化；从失败中学习，而不是指责失败。

持续部署就是这种理念的一个很好的例子。使用持续部署的团队通过监控来检测故障。他们每一两个小时部署一次，这样既能及早发现故障，又能减少故障的影响。他们使用 "金丝雀 "服务器将失败的后果降到最低，并利用每次失败来了解自己的极限并加以改进。与直觉相反，拥抱失败会带来更低的风险和更好的结果。

失败可能不可避免，但这并不妨碍成功。

失败的本质

我们很容易将失败视为简单的因果关系--A 做了这件事，导致了 B，进而导致了 C--但实际情况并非如此。⁴实际上，失败是整个开发系统的结果，而工作就是在这个系统中进行的。(你的开发系统就是你如何构建软件的方方面面，从工具到组织结构。这与你的软件系统形成鲜明对比，后者才是你正在构建的东西）。每一次失败，无论多么轻微，都是有关开发系统性质和弱点的线索。

失败是许多相互作用事件的结果。小问题不断出现，但系统有规范将其控制在安全范围内。程序员犯了一个错误，但他们的配对伙伴建议进行测试以发现错误。一位现场客户对一个故事解释不清，但在客户审核时发现了误解。一名团队成员不小心删除了一个文件，但持续集成拒绝了他的提交。

当失败发生时，不是因为单一原因，而是因为多件事情同时出错。程序员犯了一个错误，而他们的配对伙伴因为要照顾新生儿而熬夜，却没有注意到；团队正在尝试减少配对交换的频率；金丝雀服务器警报被意外禁用。失败之所以发生，不是因为问题，而是因为开发系统--人员、流程和业务环境--允许问题结合在一起。

此外，系统还表现出向失败的偏移。具有讽刺意味的是，对于有失败记录的团队来说，威胁不是错误，而是成功。随着时间的推移，随着失败的减少，团队的规范也会随之改变。例如，他们可能会让配对成为可选项，这样人们在工作方式上就有了更多选择。他们的安全边界缩小了。最终，失败的条件--这些条件一直都存在！--以适当的方式结合在一起，超越了这些较小的界限，失败就发生了。

很难看到失败的趋势。每一次改变都很小，而且都是在速度、成本、便利性或客户满意度等其他方面的改进。为了防止偏离，你必须保持警惕。过去的成功并不能保证未来的成功。

你可能会认为大失败是大错误的结果，但失败并非如此。没有单一的原因，也没有比例关系。大失败与小失败一样，都是系统性问题造成的。这是个好消息，因为这意味着小失败是大失败的 "彩排"。从小型失败中学到的东西与从大型失败中学到的东西一样多。

因此，要把每一次失败都当作学习和改进的机会。一个错字仍然是失败。发布前发现的问题仍然是失败。无论大小，如果你的团队认为某件事已经 ...