小鴿子看世界2017-04-17 11:35:54有一次，我們在將應用轉移至更快的硬碟時，資料庫出現了問題。但這問題只在晚上出現了，白天並沒有錯誤。最後我們發現，是這個應用使用了“wallclock”的時間為資料庫的主鍵記微秒，當系統閒置時，它通常會快速執行，其速度足以在同一微秒內生成兩個記錄，所以第二個“輸入”就會因主鍵錯誤而失敗。但這和大多數的故障不同，大多數的故障是在系統承受巨大壓力時出現的，而這個故障“出現在晚上”，也就是說是在系統輕負荷的時候出現的。排除故障就更有趣了，因為除錯需要假裝登入應用，這和正常的“輸入”還是有很大差別的，因為設想中的記錄並不存在。
在記憶偵錯程式的前幾天，我嘗試除錯Postgres的一個系統崩潰。這個崩潰僅在編譯程式的“除錯選項”無法工作時才會發生，所以我無法簡單地將其“鉤入到除錯”，然後等待其崩潰，而實際的崩潰正在執行多年的程式碼中發生。最終，我想到，我可以用一種二進位制搜尋方法，使單獨的原始檔除錯癱瘓，逐個進行，直到找到崩潰的檔案。Postgres有數百個檔案，所以這個過程花費了一些時間。一旦我找到崩潰的具體是哪個檔案，我就能發現什麼在最近發生了改變，然後我意識到新程式碼超過陣列末尾。這就是經典的“海信故障”。
就一會兒功夫，我解決了一串網路故障，從三方應用糟糕的多線程式碼中找到了更多樂趣。其實這些還不算什麼，因為通常你並沒有其他選擇，只能新增無數次的登入，只為找到故障所在。
