高鐵上週全線停駛4小時, 造成不少人的困擾, 同時也成為經典 "重開治百病" 的最佳案例. XD
註: 通車6年, 首次非天災造成的大規模停駛, 從 AM 6:30 ~ 11:30, 共停駛44班列車, 延誤約35000名旅客.
高鐵停擺 的 重開機治百病
高鐵這次的故障, 首先是看到這篇新聞, 雖然拖延到時間, 不過作法是蠻正確的, 下述摘錄自此篇: 高鐵號誌異常 靠重開機解決
- 陳強表示，台灣高鐵原本就排定今天要更換發現故障的轉換器，不料卻出現從未見過的警訊，2組號誌的電子連鎖轉換器都出現異常。
- 台灣高鐵發現，台中站區前後60公里，列車無法自動行駛，連在場的日本技師打電話回日本也找不出原因。
- 台灣高鐵是在清晨5時4分發現訊號異常，6時20分決定上午9時30分前，全線列車停駛。
- 陳強說，因這次異常情形超乎想像，也是從未有過的經驗，維修人員嘗試各種解決方法後都無解，過了上午9時只好做了最不得已的選擇，重新設置號誌連鎖系統，也就是重新開機，號誌也很快恢復正常。
- 陳強表示，雖然在號誌異常下，列車可以手動方式通行，但速度只能維持約時速30公里，為避免造成嚴重誤點，才決定全線停駛。
- 陳強說，今天只是暫時排除號誌異常現象，後續仍會請原廠協助釐清原因。
基本上, 故障的時候, 最好能夠維持當下的環境, 然後找出可以重複發生的原因(可以 reperduce 問題), 再來將此問題修復.
這種救火通常都蠻苦的, 在各種壓力下, 還要在牽涉那麼多套的系統裡面找出問題, 確實並不容易.
在某些特定時間點出現的問題, 那時間點過後, 全部查起來都是一切正常, 反而會非常困難的.
當確認無法短時間查明原因後, 就會選擇先讓系統可以正常運作的選項, 避免造成更大的損失, 於是就會考慮嘗試一些快速解法, ex: 重新開機~ (註: 重新開機並不一定能解決問題, 只不過, 這是最常使用的選項之一)
至於重開治百病, 好處是"可能"可以很快修復, 缺點就是, 當下的環境消失了, 問題再追蹤的可能性降低. 重開後能做的事情, 就是在猜想可能有問題的地方安插追蹤程式, 等下次發生 或 快發生時, 比較有機會快速找到問題來修復它. 但是, 一般為了避免再次發生, 延伸出的想法猜出來的: 每天固定時間重開機. XD
至於此篇新聞的批評: 幾分鐘可解決的故障 高鐵竟停擺4小時, 雨蒼大大在這篇: 從高鐵延誤看被輕視的專業 有探討, 就不再多說了~
沒空看整篇內容的, 可以先看此段(下述摘錄自: 從高鐵延誤看被輕視的專業):
撰寫過軟體或是維護過資訊系統的人應該很清楚，一個系統出了問題，第一件事情絕對不是，也不該是重開機。有問題出現，代表一定是有程式在特定的系統環境下出錯了。要找出問題，除了從程式碼來尋找以外，還要從系統環境來找。這兩個要素湊起來才能找到問題。但重開機就直接把系統環境還原，因此引發問題產生的原因消滅了，就很難再次找到原因了。重開機看起來是短時間解決了問題，但是問題並沒有真正被解決。一旦滿足了問題發生的條件，這個問題還是會再度出現。
當然, Hank 大大的猜想, 我也是覺得可能性很高: 可能有人把乖乖吃了....