棍! 廠商寫的系統訊息亂七八糟 - 論規範外包商Error Handling的重要(下)

三、法則2: 應妥善處理前端錯誤訊息, 應引導使用者排除問題

如果您不希望天天有客戶打電話進來客訴, 就得讓錯誤訊息, 能引導使用者自已排除問題, 這項需求的確認比較麻煩, 可能需要透過與下包商情境的商談來事先定義, 並透過第一線客服人員或直接由使用者試用。當然, 最好是錯誤訊息可以不用透過修改程式, 直接以 config file / resource file 的方式, 由維運人員依上線後的客訴情況來微調錯誤訊息。

但要注意, 詳細的引導可能會讓你的系統更新困難, 因此一些常變動, 但分散在各頁面的部份, 像客服電話號碼, 或某個常變動的權限申請程序, 應要求廠商讀取相同 config, 或 Link到同一則 FAQ。

四、法則3: 應妥善處理前端錯誤訊息, 不可透露程式安全細節

有時程式錯誤, 廠商為了方便debug, 會把程式哪行出錯的訊息dump在畫面上, 甚至還包含了IP, DB Account, Password 等資訊, 不禁叫人捏一把冷汗。近年來一些 Application Server 已支援 "開發模式" 與 "上線模式", 上線模式時會自動隱藏錯誤細節。但無論透過什麼方式, 廠商必須遵守 "catch 所有可能錯誤" 的原則, 畢竟沒有一位高階主管在看到系統彈出醜醜的 "Http 500 Interal Server Error" 時, 會覺得你負責的系統做的棒極了!

五、法則4: 後端錯誤log應越詳細越好

為了追蹤問題, 後端錯誤log當然應越詳細越好。若系統流量很大, 為了分析方便, 可考慮要求廠商log應該是 "可被匯入DB分析的", "具備自動rotate或灌爆警示的功能。完整的記錄欄位除了發生錯誤的trace stack之外, 還可依需求包含來源IP、案件代號、發生時間、輸入資料等資訊, 以便連結到特定客訴使用者行為, 或進行錯誤類型的統計。