网络工程师的现实（面条和……盐？）
最近，在与工程师讨论各种事件时，我注意到一个有趣的模式。
在这些讨论中，总是会出现“根本原因”的问题。 忠实的读者可能知道我有 上 。 在许多组织中，事件分析完全基于这个概念。 他们使用不同的技术来识别因果关系，例如 。 这些方法将所谓的“事件线性”视为无可争议的教条。
当你挑战这个想法并指出线性在复杂系统中确实具有欺骗性时，一场有趣的讨论就诞生了。 争论者们热情地坚持认为，只有了解“根本原因”才能让我们了解正在发生的事情。
我注意到一个有趣的模式：开发人员和开发人员对这个想法的反应不同。 根据我的经验，开发人员更有可能认为根本原因很重要，并且事件中总是可以建立因果关系。 另一方面，DevOps 通常认为复杂的世界并不总是遵循线性。
我一直想这是为什么呢？ 什么 品牌 程序员会像这样批评“根本原因是神话”的想法吗？ 就像识别外来代理的免疫系统一样。 为什么他们会这样反应，而 DevOps 相当倾向于 考虑这个想法吗？
我不完全确定，但对此我有一些想法。 它与这些专业人员开展日常工作的不同环境有关。
开发人员经常使用确定性工具。 当然，编译器、链接器、操作系统——所有这些都是复杂的系统，但我们习惯于它们给出确定性结果，并且我们将它们想象为确定性的：如果我们提供相同的输入数据，那么我们通常期望这些系统的输出相同。 如果输出存在问题（“bug”），那么开发人员可以通过分析输入数据（来自用户或开发过程中的一组工具）来解决它。 他们寻找“错误”，然后更改输入数据。 这修复了“错误”。
软件开发的基本假设：相同的输入数据可靠且确定地产生相同的输出。
事实上，非确定性结果本身就被认为是一个错误：如果未重现意外或错误的输出，那么开发人员倾向于将调查扩展到堆栈的其他部分（操作系统、网络等），这些部分的行为也相同或多或少是确定性的，用相同的输入数据产生相同的结果......并且 如果不是，那么这仍然被认为是一个bug。 现在只是操作系统或网络错误。
无论如何，对于程序员所做的大多数工作来说，决定论是一个基本的、几乎被视为理所当然的假设。
但对于任何花一天时间组装硬件或弄清楚云 API 的开发人员来说，完全确定性世界的想法（只要它甚至可以显示所有输入！）充其量只是一个转瞬即逝的概念。 就算你把它放在一边 ，经验丰富的工程师见过这个世界上最奇怪的事情。 他们知道 ，更不用说环境中数以百万计的其他因素了。
因此，经验丰富的工程师更容易怀疑所有事件都有一个根本原因，而“五个为什么”等技术将正确（并且可重复！）导致该根本原因。 事实上，这与他们自己的经验相矛盾，在实践中，拼图块并没有那么整齐地组合在一起。 因此，他们更容易接受这个想法。
当然，我并不是说开发人员天真、愚蠢或无法理解线性如何具有欺骗性。
但在我看来，开发人员在这些辩论中的共同反应往往与以下事实有关：决定论的概念 总体来说为他们服务得很好 在日常工作中。 他们不会像工程师在基础设施上遇到薛定谔的猫那样经常遇到不确定性。
这可能无法完全解释观察到的开发者反应，但它有力地提醒我们，我们的反应是许多因素的复杂混合物。
无论我们是在处理单个事件、在软件交付管道上进行协作，还是试图理解更广阔的世界，记住这种复杂性都很重要。
来源： habr.com