软件系统是社会技术的，当我们从社会技术角度看待软件时，我们开始意识到软件开发和运营中固有的复杂性。我们正在构建和运行的系统不断被不同的人修改，在不同的背景下，在不同的时间，他们可能会也可能不会直接与你沟通交流这种变动。这种紧急的协作可以带来独特的挑战。
在我职业生涯的早期，我认为软件系统是静态的、不变的实体。如果您曾经将服务地图或架构图视为灵丹妙药（而不是另一个镜头），或者您曾经谈论过“完成”软件，那么您可能已经做了同样的事情。然而，当我们以这种方式思考软件时，我们忽略了一个基本特性——人们在不断地改变软件，而这些人几乎肯定有不同的短期和长期目标、环境和压力。即使处于“维护模式”的软件也有错误修复、环境变化以及它支持的使用模式类型的变化。
当我们将人类行为添加到我们的系统中时，很明显该系统是社会技术的。
人类正在做这项工作，并且在他们所做的改变背后有其上下文。但是他们从哪里得到这个上下文呢？通常是因为参与了特定的事件。我非常赞同事故是计划外投资的观点。这些投资的回报是学习。
因此，从分析事件中汲取的经验教训可以揭示有关您的技术系统、组织以及各个部分如何相互作用的重要信息。
事件为我们所做的工作提供了上下文背景。如果我们对 MySQL 8 迁移有任何疑问，答案可能来自“MySQL 整理”事件中发生的任何事情。以这种方式可视化我们的系统还可以清楚地表明，事件可以成为强大的讲故事机制。投资于高质量的事件记录可以为事后加入的工程师扩展事件的价值。
但是，我们永远不会将所有上下文都放入一个模型中。我们可以继续前进，添加越来越多的上下文。例如，一个引人入胜的事情是标志着 COVID 大流行的开始，当一个可能位于同一地点的团队开始远程工作时，压力和倦怠风险大大增加。否则，我们最终将包括整个世界，但不断缩小并查看新镜头如何帮助构建我们的观点是很有趣的。
所以我们的系统是社会技术的！该怎么办？我认为答案很明显，您首先要投资于系统的社交部分。如果您想了解您的系统为何以它们的方式运行，则有必要了解专业知识是如何在组织中的人员中创建和分配的。做到这一点的唯一最佳方法是投资于事件分析。
许多组织采用了在事件发生后进行“事后分析”或“回顾”的做法。回顾很棒！不幸的是，我认为通过采用模板驱动的过程，对所发生的事情产生了肤浅的理解，很多学习都被搁置了。
投资于事件分析将使团队能够发现他们所知道的，几乎同样重要的是，他们如何知道他们所知道的。这是理解您的系统的社会方面的必要部分