围绕事件教训打造网络社区(2019年)
我们正处于软件时代，从事件中学习对于我们公司的持续成功至关重要。对于软件工程师来说，这是一个巨大的机会，他们可以更多地了解弹性工程、人的因素和系统安全在日常工作中的应用，目的是了解我们如何从事件和意外事件中提取价值和建立专业知识。我创建这个网站/社区是为了帮助长期的、新的和有抱负的软件工程师和领导者更多地了解这些领域，并通过对话、研究和思想共享在他们的组织中实践这些领域。
作为一个行业，我们倾向于认为我们目前对事件的处理是合理的，并从中吸取了教训；这在会议讨论、博客和更多重复了几乎是其他安全关键型行业基本建议的一般性建议中得到了证明(是的，软件是安全关键型的)。然而，我并没有看到我们经常用批判的眼光看待像SRE这样的概念和今天流行的其他形式的软件安全最佳实践。因此，我们在如何从事故、险些失误等实际改进方面限制了自己。组织在软件安全方面最大的问题仍然是没有花时间了解他们可能落后于曲线的程度。
软件行业似乎已经接受了事件审查的“无懈可击”方法的概念(正如John Allspaw和Etsy向软件行业介绍的那样，后来在Google SRE一书中得到普及)。我把“无可指责”放在引号里，因为我看到大多数组织没有这样做，而是做了一种“责备之舞”，我们知道我们不应该说这是谁的错，但我们仍然在思考，这以被动的方式表现出来。这在一定程度上是因为没有自我批评SRE的行业最佳实践，以及该领域缺乏发展。我们听到了许多关于SRE最佳实践的思想领导，并将指针移至5个9，但我不得不怀疑：
我们的组织是否真的在这些“sre”思维模式下变得更加可靠，或者我们只是通过掩盖我们的流程和9的问题而感觉更好？
我试图将事件分析提炼到一个对我来说新的组织中，方法与我在以前的组织中所做的类似：介绍一个关于Sidney Dekker的“理解人为错误的现场指南”的读书俱乐部。到目前为止，这本书是从心理学、组织行为、人的因素和弹性工程的角度而不是从技术上的“减少错误”的角度来思考事件的最好的入门。我发布了一条关于它的快速消息，有几个人注册了-更好的是，在第一次会议之前，人们已经开始分享他们对写作本身的兴奋、怀疑和批评！其中一个批评尤其来自该公司的一位非常资深的工程师--这个人的名字可以大声说出来，所有的工程师都知道这个名字在技术决策中很有分量。他们在聊天室里写了一些类似这样的话：
“我不得不说，我有兴趣讨论这个问题……但我全心全意相信‘人为错误’。”我犯了错误，他们已经造成了真正的后果，问问我所爱的人。“。
在那次声明之后，房间里的文字闲聊(至少是以兴奋的形式)减少了一点。一位非常高级的工程师发表了一个笼统的，但两极分化的声明，在我们即将一起讨论的书中受到了猛烈抨击，并谈到了一种从组织角度来看实际上是有害的思维方式。我很兴奋能亲自讨论这个问题，并渴望听到更多他们对前几章的看法。他们的反应是那些浏览过这本书的人的普遍反应，这是我要上钩并从中汲取的诱饵。
我们都可以说我们“犯了错误”，它们影响了其他人，这是无关紧要的--特别是从组织的角度来看。关键是要问一问，怎么可能会“犯那个错误”呢？
这也令我想起另一个故事，凌晨3时发生了一件事(所有不好的事都发生了，对吗？)。我的任务是在事后领导对这起高度显眼的事件的调查，但第二天早上，一名高级工程领导在办公室把我拉到一边，并说了一些大致如下的话。
“我不知道你分析这件事有没有那么有趣。”
“嗯，因为这都是(私下说的)‘人为错误’。(基兰)不知道他在做什么，也不准备拥有这个系统。本来可以等到早上的。“。
这是在一个认为他们在实践“无可指责”而没有深入理解的组织中，当发生这样的事情(Kiran会犯“错误”)时，通常会在组织内发布新的规则或流程，而不公开表示您认为这是Kiran的错。这仍然是罪魁祸首。它不仅没有生产力，而且实际上正在损害您的组织在事件发生后产生新见解和建立专业知识的能力。添加规则和程序也更容易。它遮盖了我们的屁股，让我们在情感上“继续前进”。这些新规则和程序的实现通常也不是来自第一线的人。这是因为事后很容易发现错误，而要鼓励洞察力则困难得多。不幸的是，增加新的规则和程序实际上削弱了从这些事件中收集新见解的能力。
当陈述一起事件是“人为错误”的结果时，这通常是调查已经结束的迹象。通常，在重大事故发生后，当我们在新闻中看到“人为错误”时，这是有原因的：我们更容易在情感上处理这是某人的错的想法。更难处理的事实是，这起事件是一个复杂的系统以复杂的方式相互作用的结果。但是，当我们声称“人为错误”是一个“原因”时，不管我们是否共享其他“原因”、贡献者或促进者，我们都会完全削弱分享这些其他贡献者的观点，并将注意力从他们身上转移开。
十个月前，我意识到我正在进行许多关于人的因素、弹性工程和系统安全的精彩对话，但它们分布在广泛的沟通渠道上。这在很大程度上是我在隆德大学注册的硕士课程的结果。我想把所有这些人聚集在一个地方-我们分享的想法是，当我们一起工作时，学习和理解事件的效果最好，这里需要解开的东西比软件到目前为止所做的要多得多。如果我们不聚在一起讨论这个问题，我们怎么能推动这个行业向前发展呢？我为直接在这些地区工作的人创建了一个小社区。
我们200多人的团队(不过，我并不认为这个社区的成员数量是成功的)已经一起学习和成长了将近一年。我们正在相互学习和教授有关组织行为、人的因素、弹性工程等方面的知识--在我们的组织中实施这些学习，然后进行报告。我们进行了一些我职业生涯中最具启发性和发人深省的对话。这些教训不应该留给我们自己。我们已经决定是时候开始与业内其他人分享我们学到的一些东西了。
这并不完全是我的问题--这是我的一个激情项目，但这个项目真正持续成功的原因是我的管理员同事每天与我一起工作，为人们创造一个友好、安全的合作和分享空间：
在这个名为“从软件事件中学习”的网站中，你将听到这些社区成员的真实故事--他们是软件专业人士，他们是安全关键行业的专业人士，他们是研究组织行为学的研究人员，他们是产品设计师--他们在分享从组织中的事件中学习如何在实践中奏效，以及如何没有。关于学习和实施真实事件分析的故事。关于为什么它很重要的故事。你还会听到扎根于实践的学术参考。已经有无数的研究和研究表明，从事件中吸取教训如何以及为什么采取不同的方式很重要。但最重要的是，你在这个地方看到和听到的话都是人们“劈柴运水”说的。伴随着这些故事，您将听到(通过即将到来的播客)和阅读到软件行业的行动号召。在软件安全委员会和检查表认为软件“安全”或“不安全”之前，我们有机会将这种思想嵌入到我们的组织中。
我们来这里是为了重塑软件行业对事件、软件可靠性以及人们在保持系统运行中所扮演的关键角色的看法。如果这个社区取得成功，人们将以与以前完全不同的方式进行和思考事件分析-不仅将其作为一个宝贵的镜头，让人们不仅了解事件的来源，而且了解通常阻止事件发生的因素，人们从事件中学到(和不学)什么，以及是什么让事件在尘埃落定很久之后才变得重要。
我们在这里挑战传统观点，我们将带来研究来支持我们。
本周我们每天都会有一篇关于这些故事的新帖子，然后，每周都会有一篇新帖子。您可以使用本页底部的表格注册时事通讯。
以下是我们为您准备的文章主题的一些示例：
事件分析--它到底是什么，它可能使用什么来理解成功一个组织如何在软件中实现“新观点”思维反馈和成功案例--在事件审查中耐心等待--这应该需要多长时间？传授“气味”--通过事件分析、公共与私人事件审查等方式提炼专业知识！
哈莉，这是杰西卡。2014年。无懈可击的真正含义是什么。http://www.jessicaharllee.com/notes/what-blameless-really-means/Klein，加里。2014年。不，您的组织确实赢得了创新。https://www.wired.co.uk/article/gary-klein科瓦尔斯基，凯尔。论启蒙：“劈柴运水”禅宗语录的三层含义。https://www.sloww.co/enlightenment-chop-wood-carry-waterShorrock史蒂文。人的错误之后的生活。https://www.youtube.com/watch?v=STU3Or6ZU60斯努克，斯科特报道。2002年。友军火力。
“仍然不安全：病人安全与美国医学的中期管理”。
