iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
佛心分享-IT 人自學之術

It Works on My Machine:30 天從踩雷學會工程事故調查 系列

本系列從五個親身踩過的工程問題出發,記錄我如何從「我這邊明明正常」開始,查閱文件、保存證據、建立最小重現、重建事件軌跡,逐步搞懂需求定義、執行環境、資料契約、工具語意與非同步完成條件。這不是 30 天抓戰犯,而是把每一次踩雷整理成可重複使用的工程事故調查方法。It Works on My Machine 不是結論,而是事故調查與重新學習的起點:IDE 能跑,Terminal 卻失敗;語法完全合法,一個逗號卻悄悄把資料型別換掉;lint 與自動修正全數通過,ORM 查詢反而永遠撈不到資料;系統明明採用非同步 Pub/Sub,卻被要求立刻回答遠端指令成功了沒。

鐵人鍊成 | 共 30 篇文章 | 2 人訂閱 訂閱系列文 RSS系列文
DAY 21

Day 21|踩雷:Pub/Sub 都非同步了,你還要我立刻回答成功沒?

本篇是故事五的「踩雷」篇。 本篇要回答:一個看似合理的介面需求——「回傳指令是否成功」——為什麼在非同步架構裡是一道無解題? 當時發生了什麼 系統採用非同步...

2026-08-26 ‧ 由 notwisebenson 分享
DAY 22

Day 22|查證:送出、送達、受理、執行與完成,到底哪一個叫成功?

本篇是故事五的「查證」篇。 本篇要回答:非同步命令的調查需要保存哪些證據?每一份證據能證明什麼、不能證明什麼? 當時發生了什麼 Day 21 把「成功」拆成...

2026-08-27 ‧ 由 notwisebenson 分享
DAY 23

Day 23|重現:一個指令要走過多少層,才有資格說完成?

本篇是故事五的「重現」篇。 本篇要回答:非同步命令的生命週期該怎麼建模,才能讓「完成」變成可驗證的狀態而不是一句宣稱? 當時發生了什麼 Day 22 的收據...

2026-08-28 ‧ 由 notwisebenson 分享
DAY 24

Day 24|理解:不是 Pub/Sub 不能回應,是我們把整個生命週期硬塞進一個 bool

本篇是故事五的「理解」篇。 本篇要回答:同步布林介面與非同步處理語意的衝突,具體會逼系統做出哪些錯誤選擇? 當時發生了什麼 Day 23 的八個狀態,對照介...

2026-08-29 ‧ 由 notwisebenson 分享
DAY 25

Day 25|內化:先回 Command ID,再讓執行結果循著事件回來

本篇是故事五的「內化」篇。 本篇要回答:把「拒絕用一個 bool 說謊」落成一份可實作的非同步命令契約,長什麼樣子? 當時發生了什麼 拒絕一個需求的正確姿勢...

2026-08-30 ‧ 由 notwisebenson 分享
DAY 26

Day 26|每一層都說自己正常,為什麼整套系統還是不能用?

本篇是最後五天方法回顧的第一篇。 本篇要回答:五個故事各踩在不同的技術層,為什麼說它們是同一種事故? 五種局部成功 把五個故事各自最理直氣壯的一句話排在一起...

2026-08-31 ‧ 由 notwisebenson 分享
DAY 27

Day 27|沒有保存證據,就只能靠每個人回憶自己的清白

本篇是最後五天方法回顧的第二篇。 本篇要回答:工程事故的最低證據保存清單長什麼樣?為什麼「事後再收集」通常來不及? 當時發生了什麼——五個故事的證據帳單 回...

2026-09-01 ‧ 由 notwisebenson 分享
DAY 28

Day 28|從需求到外部效果,畫出一條可以被驗證的事件軌跡

本篇是最後五天方法回顧的第三篇。 本篇要回答:有了證據之後,怎麼把它們組織成一條能支撐結論的軌跡,而不是一堆按時間排序的 log? 五個故事,五條軌跡 回看...

2026-09-02 ‧ 由 notwisebenson 分享
DAY 29

Day 29|不要急著找戰犯:直接原因、促成因素與系統性缺口

本篇是最後五天方法回顧的第四篇。 本篇要回答:為什麼「找到根因」經常是調查提前結束的藉口?原因分析的固定格式長什麼樣? 找戰犯的引力 事故調查有一股天然引力...

2026-09-03 ‧ 由 notwisebenson 分享
DAY 30

Day 30|修好不等於不再發生:改善措施也需要驗收

本篇是最後五天方法回顧的最後一篇,也是全系列的收束。 本篇要回答:怎麼分辨一項改善措施是真的防再發,還是只是多了一份文件? 無效措施的五種經典款 「下次注意...

2026-09-04 ‧ 由 notwisebenson 分享