本系列從五個親身踩過的工程問題出發,記錄我如何從「我這邊明明正常」開始,查閱文件、保存證據、建立最小重現、重建事件軌跡,逐步搞懂需求定義、執行環境、資料契約、工具語意與非同步完成條件。這不是 30 天抓戰犯,而是把每一次踩雷整理成可重複使用的工程事故調查方法。It Works on My Machine 不是結論,而是事故調查與重新學習的起點:IDE 能跑,Terminal 卻失敗;語法完全合法,一個逗號卻悄悄把資料型別換掉;lint 與自動修正全數通過,ORM 查詢反而永遠撈不到資料;系統明明採用非同步 Pub/Sub,卻被要求立刻回答遠端指令成功了沒。
本篇是故事五的「踩雷」篇。 本篇要回答:一個看似合理的介面需求——「回傳指令是否成功」——為什麼在非同步架構裡是一道無解題? 當時發生了什麼 系統採用非同步...
本篇是故事五的「查證」篇。 本篇要回答:非同步命令的調查需要保存哪些證據?每一份證據能證明什麼、不能證明什麼? 當時發生了什麼 Day 21 把「成功」拆成...
本篇是故事五的「重現」篇。 本篇要回答:非同步命令的生命週期該怎麼建模,才能讓「完成」變成可驗證的狀態而不是一句宣稱? 當時發生了什麼 Day 22 的收據...
本篇是故事五的「理解」篇。 本篇要回答:同步布林介面與非同步處理語意的衝突,具體會逼系統做出哪些錯誤選擇? 當時發生了什麼 Day 23 的八個狀態,對照介...
本篇是故事五的「內化」篇。 本篇要回答:把「拒絕用一個 bool 說謊」落成一份可實作的非同步命令契約,長什麼樣子? 當時發生了什麼 拒絕一個需求的正確姿勢...
本篇是最後五天方法回顧的第一篇。 本篇要回答:五個故事各踩在不同的技術層,為什麼說它們是同一種事故? 五種局部成功 把五個故事各自最理直氣壯的一句話排在一起...
本篇是最後五天方法回顧的第二篇。 本篇要回答:工程事故的最低證據保存清單長什麼樣?為什麼「事後再收集」通常來不及? 當時發生了什麼——五個故事的證據帳單 回...
本篇是最後五天方法回顧的第三篇。 本篇要回答:有了證據之後,怎麼把它們組織成一條能支撐結論的軌跡,而不是一堆按時間排序的 log? 五個故事,五條軌跡 回看...
本篇是最後五天方法回顧的第四篇。 本篇要回答:為什麼「找到根因」經常是調查提前結束的藉口?原因分析的固定格式長什麼樣? 找戰犯的引力 事故調查有一股天然引力...
本篇是最後五天方法回顧的最後一篇,也是全系列的收束。 本篇要回答:怎麼分辨一項改善措施是真的防再發,還是只是多了一份文件? 無效措施的五種經典款 「下次注意...