网络工程师的现实（包括面条和盐？）最近，在与工程师讨论各种事件时，我注意到了一个有趣的模式。
在这些讨论中，总是会出现“根本原因”问题。 忠实的读者可能会知道，我
对此有
一些 想法 。 在许多组织中，事件分析完全基于此概念。 他们使用不同的技术来识别因果关系，例如“
五个为什么” 。 这些方法表明了所谓的“事件线性”是不可否认的教条。
当您对这个想法提出质疑并指出复杂系统中的线性具有欺骗性时，就产生了一个有趣的讨论。 辩论者充满激情地坚持认为，只有对“根本原因”的了解才能使我们了解正在发生的事情。
我注意到一个有趣的模式：开发人员和开发人员对此想法的反应不同。 根据我的经验，开发人员通常会争辩说根本原因很重要，并且因果关系总是可以在事件中建立。 另一方面，开发人员更经常同意复杂的世界并不总是受线性影响。
我一直想知道为什么会这样？ 是什么
使程序员批评“根本原因-神话”的观念？ 就像识别异物的免疫系统一样。 为什么他们
会以这种方式做出反应，而开发人员
更可能考虑这个想法？
我不太确定，但是在这方面需要考虑。 它与这些专业人员执行日常工作的各种环境相关联。
开发人员经常使用确定性工具。 当然，编译器，链接器，OS都是复杂的系统，但是我们习惯于给出确定性的结果，并且将它们表示为确定性的：如果我们提供相同的输入数据，则通常期望这些系统具有相同的输出。 并且，如果存在问题（“错误”），则开发人员可以通过分析输入数据（来自用户或开发过程中的一组工具）来解决问题。 他们寻找“错误”，然后修改输入。 这修复了该错误。
软件开发的主要假设：相同的输入数据可靠且确定地给出相同的输出实际上，不确定性结果本身就是错误：如果未重现意外或错误的结论，则开发人员将研究扩大到堆栈的其他部分（操作系统，网络等），这些部分或多或少地具有确定性，给出相同的结论输入相同的结果...，
如果不是 ，则仍视为错误。 只是这现在是操作系统或网络的错误。
无论如何，对于程序员所做的大多数工作，确定性都是基本的，几乎是理所当然的假设。
但是对于所有花一天时间在架子上收集铁或处理云API的devopa，一个完全确定性的世界（只要有机会显示所有输入数据！）的想法充其量只是一个短暂的概念。 即使抛开
BOHF关于太阳斑的笑话 ，经验丰富的工程师也看到了这个世界上最奇怪的事情。 他们知道，
即使是人为的尖叫也会降低服务器的速度 ，更不用说数百万其他环境因素了。
因此，有经验的工程师更容易怀疑所有事件都有一个根本原因，而诸如“五个为什么”之类的技术正确（且可重复！）会导致该根本原因。 实际上，这与他们自己的经验是矛盾的，因为在实践中，拼图块的积淀并没有那么清楚。 因此，他们更容易理解这个想法。
当然，我并不是说开发人员天真，愚蠢或无法理解线性如何欺骗。
经验丰富的程序员在他们的一生中可能还会看到很多不确定性。但是在我看来，开发人员在这些纠纷中的通常反应通常与以下事实有关：确定性概念
作为一个整体在日常工作中
可以很好地为他们服务 。 它们不会像工程师不得不在其基础架构上捉住薛定inger猫那样频繁地遇到不确定性。
也许这不能完全解释开发人员所观察到的反应，但这有力地提醒我们我们的反应是许多因素的复杂混合。
无论我们是在调查单个事件还是在软件交付管道上共同努力，还是试图使整个世界变得有意义，都必须牢记这种复杂性。