網路工程師的現實（麵條和…鹽？）
最近，在與工程師討論各種事件時，我注意到一個有趣的模式。
在這些討論中，總是會出現「根本原因」的問題。 忠實的讀者可能知道我有 上 。 在許多組織中，事件分析完全基於這個概念。 他們使用不同的技術來識別因果關係，例如 。 這些方法將所謂的「事件線性」視為無可爭議的教條。
當你挑戰這個想法並指出線性在複雜系統中確實具有欺騙性時，有趣的討論就誕生了。 爭論者們熱情地堅持認為，只有了解「根本原因」才能讓我們了解正在發生的事情。
我注意到一個有趣的模式：開發人員和開發人員對這個想法的反應不同。 根據我的經驗，開發人員更有可能認為根本原因很重要，而且事件中總是可以建立因果關係。 另一方面，DevOps 通常認為複雜的世界並不總是遵循線性。
我一直想這是為什麼呢？ 什麼 使 程式設計師會像這樣批評「根本原因是神話」的想法嗎？ 就像辨識外來代理人的免疫系統一樣。 為什麼他們會這樣反應，而 DevOps 相當傾向於 考慮這個想法嗎？
我不完全確定，但對此我有一些想法。 它與這些專業人員進行日常工作的不同環境有關。
開發人員經常使用確定性工具。 當然，編譯器、連結器、作業系統——所有這些都是複雜的系統，但我們習慣於它們給出確定性結果，並且我們將它們想像為確定性的：如果我們提供相同的輸入數據，那麼我們通常期望這些系統的輸出相同。 如果輸出有問題（“bug”），那麼開發人員可以透過分析輸入資料（來自使用者或開發過程中的一組工具）來解決它。 他們尋找“錯誤”，然後更改輸入資料。 這修復了“錯誤”。
軟體開發的基本假設：相同的輸入資料可靠且確定地產生相同的輸出。
事實上，非確定性結果本身就被認為是一個錯誤：如果未重現意外或錯誤的輸出，那麼開發人員傾向於將調查擴展到堆疊的其他部分（作業系統、網路等），這些部分的行為也相同或多或少是確定性的，用相同的輸入資料產生相同的結果......並且 如果不是這樣的話，那麼這仍然被認為是一個bug。 現在只是作業系統或網路錯誤。
無論如何，對於程式設計師所做的大多數工作來說，決定論是一個基本的、幾乎被視為理所當然的假設。
但對於任何花一天時間組裝硬體或弄清楚雲端 API 的開發人員來說，完全確定性世界的想法（只要有可能映射所有輸入！）充其量只是一個短暫的概念。 就算你把它放在一邊 ，經驗豐富的工程師看過這個世界上最奇怪的事。 他們知道 ，更不用說環境中數以百萬計的其他因素了。
因此，經驗豐富的工程師更容易懷疑所有事件都有一個根本原因，而「五個為什麼」等技術將正確（並且可重複！）導致該根本原因。 事實上，這與他們自己的經驗相矛盾，在實踐中，拼圖塊並沒有那麼整齊地組合在一起。 因此，他們更容易接受這個想法。
當然，我並不是說開發人員天真、愚蠢或無法理解線性如何具有欺騙性。
但在我看來，開發人員在這些辯論中的共同反應往往與以下事實有關：決定論的概念 整體來說為他們服務得很好 在日常工作中。 他們不會像工程師在基礎設施上遇到薛丁格的貓那樣經常遇到不確定性。
這可能無法完全解釋觀察到的開發者反應，但它有力地提醒我們，我們的反應是許多因素的複雜混合物。
無論我們是在處理單一事件、在軟體交付管道上進行協作，還是試圖理解更廣闊的世界，記住這種複雜性都很重要。
來源： www.habr.com