<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>事故調查 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E4%BA%8B%E6%95%85%E8%AA%BF%E6%9F%A5/</link><description>Recent content in 事故調查 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Wed, 19 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E4%BA%8B%E6%95%85%E8%AA%BF%E6%9F%A5/index.xml" rel="self" type="application/rss+xml"/><item><title>後見之明偏誤：事後看得一清二楚的因果，在當下並不存在</title><link>https://tarrragon.github.io/blog/til/behavior/hindsight-bias/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/behavior/hindsight-bias/</guid><description>&lt;p>後見之明偏誤（hindsight bias）指的是&lt;strong>知道結果之後，人會系統性地高估當初該結果的可預測性&lt;/strong>。知道結局的人重建當時的情境時，會把後來證明重要的線索標得比當時更顯眼，把後來證明無關的雜訊自動略去，於是得出「這明明很明顯」的結論——而那個「明顯」是結果賦予的，不是當時就有的。&lt;/p>
&lt;p>這個現象由 Baruch Fischhoff 在 1970 年代以實驗確立，後續在醫療診斷、司法判決、金融預測等領域反覆複製。它的實驗形式很簡單：告訴一組受試者某事件的結果、另一組不告訴，兩組都估「這件事發生的機率有多高」，知道結果的那組估得明顯更高，而且他們相信自己沒有受影響。&lt;/p>
&lt;h2 id="它為什麼讓事故調查失效">它為什麼讓事故調查失效&lt;/h2>
&lt;p>事發當下的當事人看到的是&lt;strong>部分的、互相矛盾的、還在變化的資訊&lt;/strong>，而且同時有其他事情在進行。調查者看到的是一條已經收斂的時間軸，上面每個節點都已經被結果篩選過。兩者不是同一個問題的深淺差別，是兩個不同的問題。&lt;/p>
&lt;p>具體的失效形式是提問方向。「他當時怎麼會沒注意到那個警告」這個問句預設了警告在當時是顯眼的，而那正是待證明的事——當時螢幕上可能還有十七個同類警告，其中十六個是雜訊。停在這種問句的檢討會產出「加強訓練」「加簽核」「加提醒」這類措施，而它們不改變系統讓錯誤發生的條件，所以同類事故會再來。&lt;/p>
&lt;p>有效的做法是重建當事人的視角而非列出他應該注意到什麼：建立時間軸、標記各時點實際可得的資訊、找出資訊與判斷之間的合理連結。安全科學把這個轉換稱為從舊觀點走到新觀點——舊觀點認為人是系統裡不可靠的部分，新觀點認為事故顯示的是系統的條件。&lt;/p>
&lt;h2 id="跟相鄰概念的關係">跟相鄰概念的關係&lt;/h2>
&lt;p>它跟 &lt;a href="../../organization/psychological-safety/">心理安全感&lt;/a> 常一起出現而機制不同：心理安全感決定當事人&lt;strong>願不願意&lt;/strong>說出當時真正發生什麼，後見之明偏誤決定調查者&lt;strong>有沒有能力&lt;/strong>聽懂他說的。兩者都失效時，檢討會拿到一份既不完整也被誤讀的紀錄。前者是群體屬性，後者是個人認知限制，修法也不同——前者要改組織對壞消息的反應，後者要改調查程序。&lt;/p>
&lt;p>它也是規劃謬誤的鏡像。規劃謬誤是對未來過度樂觀，後見之明偏誤是對過去過度確定，兩者共用同一個機制：人對「當時能知道多少」的估計不準。&lt;/p>
&lt;h2 id="要往下讀">要往下讀&lt;/h2>
&lt;p>事故調查怎麼繞開它，看 Sidney Dekker 的《The Field Guide to Understanding &amp;lsquo;Human Error&amp;rsquo;》，選讀判斷在 &lt;a href="https://tarrragon.github.io/blog/books/software-management/topics/incident-blame/" data-link-title="事故、歸因與無指責檢討" data-link-desc="事故檢討停在人為疏失、同類事故一再發生時，用來重建當事人視角與辨認偏差累積的安全科學">事故、歸因與無指責檢討書單&lt;/a>。偏誤的完整地圖在 Kahneman 的《Thinking, Fast and Slow》，那本的選讀說明在 &lt;a href="https://tarrragon.github.io/blog/books/software-management/topics/estimation-decision/" data-link-title="估算、承諾與決策偏誤" data-link-desc="估算永遠樂觀、明知做不完還是承諾、風險沒人願意攤開講時，區分認知偏誤與誘因結構的選讀">估算、承諾與決策偏誤&lt;/a>。事故流程的制度實作看 &lt;a href="https://tarrragon.github.io/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>後見之明偏誤（hindsight bias）指的是<strong>知道結果之後，人會系統性地高估當初該結果的可預測性</strong>。知道結局的人重建當時的情境時，會把後來證明重要的線索標得比當時更顯眼，把後來證明無關的雜訊自動略去，於是得出「這明明很明顯」的結論——而那個「明顯」是結果賦予的，不是當時就有的。</p>
<p>這個現象由 Baruch Fischhoff 在 1970 年代以實驗確立，後續在醫療診斷、司法判決、金融預測等領域反覆複製。它的實驗形式很簡單：告訴一組受試者某事件的結果、另一組不告訴，兩組都估「這件事發生的機率有多高」，知道結果的那組估得明顯更高，而且他們相信自己沒有受影響。</p>
<h2 id="它為什麼讓事故調查失效">它為什麼讓事故調查失效</h2>
<p>事發當下的當事人看到的是<strong>部分的、互相矛盾的、還在變化的資訊</strong>，而且同時有其他事情在進行。調查者看到的是一條已經收斂的時間軸，上面每個節點都已經被結果篩選過。兩者不是同一個問題的深淺差別，是兩個不同的問題。</p>
<p>具體的失效形式是提問方向。「他當時怎麼會沒注意到那個警告」這個問句預設了警告在當時是顯眼的，而那正是待證明的事——當時螢幕上可能還有十七個同類警告，其中十六個是雜訊。停在這種問句的檢討會產出「加強訓練」「加簽核」「加提醒」這類措施，而它們不改變系統讓錯誤發生的條件，所以同類事故會再來。</p>
<p>有效的做法是重建當事人的視角而非列出他應該注意到什麼：建立時間軸、標記各時點實際可得的資訊、找出資訊與判斷之間的合理連結。安全科學把這個轉換稱為從舊觀點走到新觀點——舊觀點認為人是系統裡不可靠的部分，新觀點認為事故顯示的是系統的條件。</p>
<h2 id="跟相鄰概念的關係">跟相鄰概念的關係</h2>
<p>它跟 <a href="../../organization/psychological-safety/">心理安全感</a> 常一起出現而機制不同：心理安全感決定當事人<strong>願不願意</strong>說出當時真正發生什麼，後見之明偏誤決定調查者<strong>有沒有能力</strong>聽懂他說的。兩者都失效時，檢討會拿到一份既不完整也被誤讀的紀錄。前者是群體屬性，後者是個人認知限制，修法也不同——前者要改組織對壞消息的反應，後者要改調查程序。</p>
<p>它也是規劃謬誤的鏡像。規劃謬誤是對未來過度樂觀，後見之明偏誤是對過去過度確定，兩者共用同一個機制：人對「當時能知道多少」的估計不準。</p>
<h2 id="要往下讀">要往下讀</h2>
<p>事故調查怎麼繞開它，看 Sidney Dekker 的《The Field Guide to Understanding &lsquo;Human Error&rsquo;》，選讀判斷在 <a href="/blog/books/software-management/topics/incident-blame/" data-link-title="事故、歸因與無指責檢討" data-link-desc="事故檢討停在人為疏失、同類事故一再發生時，用來重建當事人視角與辨認偏差累積的安全科學">事故、歸因與無指責檢討書單</a>。偏誤的完整地圖在 Kahneman 的《Thinking, Fast and Slow》，那本的選讀說明在 <a href="/blog/books/software-management/topics/estimation-decision/" data-link-title="估算、承諾與決策偏誤" data-link-desc="估算永遠樂觀、明知做不完還是承諾、風險沒人願意攤開講時，區分認知偏誤與誘因結構的選讀">估算、承諾與決策偏誤</a>。事故流程的制度實作看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>。</p>
]]></content:encoded></item><item><title>偏差正常化：每次放寬都有理由，累積起來走到災難</title><link>https://tarrragon.github.io/blog/til/organization/normalization-of-deviance/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/organization/normalization-of-deviance/</guid><description>&lt;p>偏差正常化（normalization of deviance）指的是&lt;strong>一個群體反覆接受某個超出規格的狀況而沒有出事，於是那個狀況逐漸被重新定義成正常&lt;/strong>。它的關鍵性質是每一步都在當下是合理的：這一次的放寬有具體理由、也確實沒有造成後果，於是新的狀態成為下一次判斷的基準，下一次再從新基準往外放一點。&lt;/p>
&lt;p>這個概念由社會學家 Diane Vaughan 在《The Challenger Launch Decision》（1996）提出。她重建挑戰者號失事的決策鏈之後，推翻了當時的通俗解釋——&lt;strong>那不是有人違規或隱瞞&lt;/strong>。O 型環的侵蝕在先前多次飛行就出現過，每一次都沒有導致失敗，於是「有侵蝕」從異常訊號變成預期現象、再變成可接受風險的一部分。發射前那場著名的爭論裡，工程師拿不出「這次會出事」的證據，因為判斷基準早就移動過了。&lt;/p>
&lt;h2 id="它跟隱瞞的差別在哪裡">它跟隱瞞的差別在哪裡&lt;/h2>
&lt;p>這個區分是整個概念的重點。隱瞞有一個知道真相的人；偏差正常化沒有——參與者不是壓下了警訊，是他們真心不再認為那是警訊。所以事後追查「誰知道而沒說」會落空，而落空之後常見的結論是「大家都盡力了、只是運氣不好」，那同樣錯過了真正可改的東西。&lt;/p>
&lt;p>可改的東西是&lt;strong>判斷基準怎麼被移動的&lt;/strong>：哪一次的例外沒有被記錄成例外、哪一個「這次先這樣」沒有設回收期限、哪個原本要簽核的動作變成口頭同意。這些是可以留下痕跡、也可以設計制度去攔的。&lt;/p>
&lt;p>哥倫比亞號 2003 年失事後，調查委員會的報告直接引用了 Vaughan，並指出同一個模式在同一個組織裡再次完整發生——這也說明偏差正常化不是可以靠一次事故教訓「學會」的東西。&lt;/p>
&lt;h2 id="軟體團隊的對應形態">軟體團隊的對應形態&lt;/h2>
&lt;p>同一個機制在軟體組織裡很容易辨認，因為每一步都有當下的理由：&lt;/p>
&lt;ul>
&lt;li>這次先跳過測試，因為要趕修這個線上問題&lt;/li>
&lt;li>這次手動改生產環境，因為改設定比走流程快&lt;/li>
&lt;li>這個警報先靜音，因為它最近一直誤報&lt;/li>
&lt;li>這次先不寫檢討，因為影響範圍很小&lt;/li>
&lt;/ul>
&lt;p>單看每一條都不算離譜，而問題在於&lt;strong>沒出事本身被當成了做法沒問題的證據&lt;/strong>。跑十次沒事的手動改機，跟跑十次沒事之後第十一次改錯，是同一個做法。&lt;/p>
&lt;p>辨識訊號是「上次也是這樣」開始被用來當理由——那句話在說的正是基準已經移動。&lt;/p>
&lt;h2 id="跟相鄰概念的關係">跟相鄰概念的關係&lt;/h2>
&lt;p>它跟 &lt;a href="../psychological-safety/">心理安全感&lt;/a> 都會讓組織收不到壞消息，但機制不同：心理安全感低的組織裡有人看見了而不敢講，偏差正常化的組織裡沒有人覺得那件事需要講。修法因此也不同——前者要改組織對壞消息的反應，後者要在制度上讓例外留下痕跡並強制回收。兩者疊在一起時最難救，因為既沒有人認為要講、就算有人想講也沒有安全的說法。&lt;/p>
&lt;p>它跟 &lt;a href="../../behavior/hindsight-bias/">後見之明偏誤&lt;/a> 是事故調查裡的一對：後見之明偏誤讓調查者以為當時的訊號很明顯，而偏差正常化解釋了那些訊號當時為什麼真的不明顯——它們已經被納入正常範圍了。忽略後者的調查會停在「他們怎麼會沒發現」，而那個問句無法產出任何改動。&lt;/p>
&lt;h2 id="要往下讀">要往下讀&lt;/h2>
&lt;p>完整的個案重建看 Vaughan 的原書，它是八百頁的學術專著；選讀判斷與較輕的替代路徑在 &lt;a href="https://tarrragon.github.io/blog/books/software-management/topics/incident-blame/" data-link-title="事故、歸因與無指責檢討" data-link-desc="事故檢討停在人為疏失、同類事故一再發生時，用來重建當事人視角與辨認偏差累積的安全科學">事故、歸因與無指責檢討書單&lt;/a>。把例外留下痕跡、設定回收期限這類制度實作，看 &lt;a href="https://tarrragon.github.io/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>偏差正常化（normalization of deviance）指的是<strong>一個群體反覆接受某個超出規格的狀況而沒有出事，於是那個狀況逐漸被重新定義成正常</strong>。它的關鍵性質是每一步都在當下是合理的：這一次的放寬有具體理由、也確實沒有造成後果，於是新的狀態成為下一次判斷的基準，下一次再從新基準往外放一點。</p>
<p>這個概念由社會學家 Diane Vaughan 在《The Challenger Launch Decision》（1996）提出。她重建挑戰者號失事的決策鏈之後，推翻了當時的通俗解釋——<strong>那不是有人違規或隱瞞</strong>。O 型環的侵蝕在先前多次飛行就出現過，每一次都沒有導致失敗，於是「有侵蝕」從異常訊號變成預期現象、再變成可接受風險的一部分。發射前那場著名的爭論裡，工程師拿不出「這次會出事」的證據，因為判斷基準早就移動過了。</p>
<h2 id="它跟隱瞞的差別在哪裡">它跟隱瞞的差別在哪裡</h2>
<p>這個區分是整個概念的重點。隱瞞有一個知道真相的人；偏差正常化沒有——參與者不是壓下了警訊，是他們真心不再認為那是警訊。所以事後追查「誰知道而沒說」會落空，而落空之後常見的結論是「大家都盡力了、只是運氣不好」，那同樣錯過了真正可改的東西。</p>
<p>可改的東西是<strong>判斷基準怎麼被移動的</strong>：哪一次的例外沒有被記錄成例外、哪一個「這次先這樣」沒有設回收期限、哪個原本要簽核的動作變成口頭同意。這些是可以留下痕跡、也可以設計制度去攔的。</p>
<p>哥倫比亞號 2003 年失事後，調查委員會的報告直接引用了 Vaughan，並指出同一個模式在同一個組織裡再次完整發生——這也說明偏差正常化不是可以靠一次事故教訓「學會」的東西。</p>
<h2 id="軟體團隊的對應形態">軟體團隊的對應形態</h2>
<p>同一個機制在軟體組織裡很容易辨認，因為每一步都有當下的理由：</p>
<ul>
<li>這次先跳過測試，因為要趕修這個線上問題</li>
<li>這次手動改生產環境，因為改設定比走流程快</li>
<li>這個警報先靜音，因為它最近一直誤報</li>
<li>這次先不寫檢討，因為影響範圍很小</li>
</ul>
<p>單看每一條都不算離譜，而問題在於<strong>沒出事本身被當成了做法沒問題的證據</strong>。跑十次沒事的手動改機，跟跑十次沒事之後第十一次改錯，是同一個做法。</p>
<p>辨識訊號是「上次也是這樣」開始被用來當理由——那句話在說的正是基準已經移動。</p>
<h2 id="跟相鄰概念的關係">跟相鄰概念的關係</h2>
<p>它跟 <a href="../psychological-safety/">心理安全感</a> 都會讓組織收不到壞消息，但機制不同：心理安全感低的組織裡有人看見了而不敢講，偏差正常化的組織裡沒有人覺得那件事需要講。修法因此也不同——前者要改組織對壞消息的反應，後者要在制度上讓例外留下痕跡並強制回收。兩者疊在一起時最難救，因為既沒有人認為要講、就算有人想講也沒有安全的說法。</p>
<p>它跟 <a href="../../behavior/hindsight-bias/">後見之明偏誤</a> 是事故調查裡的一對：後見之明偏誤讓調查者以為當時的訊號很明顯，而偏差正常化解釋了那些訊號當時為什麼真的不明顯——它們已經被納入正常範圍了。忽略後者的調查會停在「他們怎麼會沒發現」，而那個問句無法產出任何改動。</p>
<h2 id="要往下讀">要往下讀</h2>
<p>完整的個案重建看 Vaughan 的原書，它是八百頁的學術專著；選讀判斷與較輕的替代路徑在 <a href="/blog/books/software-management/topics/incident-blame/" data-link-title="事故、歸因與無指責檢討" data-link-desc="事故檢討停在人為疏失、同類事故一再發生時，用來重建當事人視角與辨認偏差累積的安全科學">事故、歸因與無指責檢討書單</a>。把例外留下痕跡、設定回收期限這類制度實作，看 <a href="/blog/backend/08-incident-response/" data-link-title="模組八：事故處理與復盤" data-link-desc="用 IR 領域詞彙建問題節點、以服務級案例庫累積事故脈絡，先建概念與案例庫再進實作交接">事故處理與復盤</a>。</p>
]]></content:encoded></item></channel></rss>