看的我膽顫心驚。如果維護一個長久的服務 (也不用太大) 多半會踩到這篇文章說的。
Debugging is a Science
有同感，大型的 server 通常混了一大堆邏輯，時間久了，會越來越難找 root cause。比方說上個禮拜我們遇到的問題：某個地方存取忽然變多了，server loading 變很大，但是查了老半天卻查不出來 (我們往最近的更新去找，但查了沒結果)，很吐血。
但是還是要查出 bug 啊，我們的流程就是一直重覆：查最近的異動 -> 建立假說 -> 不可能就換另一個方向 -> 假說可行的話就試試 -> 實驗失敗就重頭來 -> 換另一個假說。
通常歷經了三~五輪的假說後才會發現真正的 root cause (時間不定，有時要一、二個月後才會發現)。最後找到 root cause 並解決是可喜可賀啦，但前面自己提的假說一直被打臉也是蠻冏的。(嘛，我發現我臉皮越來越厚了...)
Long Running Systems Have Their Own Bugs
這一點提的經驗很有意思：現在流行 continuous deployment，所以每天上線新的程式是常態，但是因為常常 restart，很多長期的疾病不會顯現出來。直到開發團隊轉往另外一個專案忙時，原來的專案過了幾個月都沒更新/重啟，然後長期性疾病就冒出來了 (通常是 leak 居多)。
這裡我的經驗與作者相同，我自己也遇到很多次了，這算是 continous deployment 的 副作用 吧？常吃抗生素病很快好但長期下來會留下一些看不見的問題。怎麼解決這種 bug ？這可不是剛上線產生的那種熱騰騰的 bug，它可能是一年前就存在了，你往最近的程式更新去查，查不出來很正常的。怎麼辦？就回到上面提的 假說>打臉>假說>打臉>... 這樣的循環了，等到臉夠腫了自然就會找到 bug 了。