[閒聊] [分享] 論規範外包商Error Handling的重要

看板Soft_Job (軟體人)作者bartschen (are you there ?)時間16年前 (2010/04/12 11:30)推噓2(2推 0噓 3→)

留言5則, 5人參與討論串1/1

「本文已取得原作者同意轉錄」 http://blog.ragic.com/tw/outsource-error-handling/ http://blog.ragic.com/tw/outsource-error-handling-2/ 棍! 廠商寫的系統訊息亂七八糟 – 論規範外包商Error Handling的重要(上) 棍! 廠商寫的系統訊息亂七八糟 – 論規範外包商Error Handling的重要(下) 到哪裡一、魔鬼降臨在總裁一句 “人事凍結” 的命令下, 身為一間大企業的MIS工程師, 展開了與外包商長期的角力。”魔鬼就在執行的細節裡” 一句話點破了外包管理省工省事的神話。為了避免包商拿了錢一拍兩散的常態, 或千拜託萬拜託卻另外要你簽個 25% MA。因此驗收合約的精細度就變得很重要, 今天要和大家談的就是規範Error Handling和Return Code這檔事。參與專案外包工作已經十個年頭, 從三五人的小公司到號稱遵循CMMI/ISO制度的大公司, 幾乎沒看到有專案, 在需求文件中對包商交付系統的 Error Handling 做規範。因此當專案結束, 維運人員接手一段日子後, 才發現原來系統傳回 “帳號密碼錯誤”, 有時候事實上是 “資料庫連線失敗” 或 “伺服器磁碟已滿”。搞得維運人員灰頭土臉, 三不五時被老闆叫去罵系統寫的爛。其實探究原因, 這是由於開發系統時, 工程師常以工程的角度去做Error Handling, 而非以維運角度去處理。 “那要如何在合約中簡單的規範下包商的處理方式呢?” 下面將建議幾個法則。 (這裡我們不談“throw early, catch late” 之類的程式編寫原則, 那是下包商工程師撰寫上的藝術, 我們在合約中不需多加干涉。) 二、法則1: “用責任區來編Error Code” 對工程師來說, 處理一個錯誤, 最重要的就是 “技術上這是哪類的錯誤?”, 分類方法可能是DB, AP, Network, … 但對維運人員來說, 看到一個錯誤, 最重要的就是 “誰該處理?”, 分類方法是 “使用者密碼錯誤-使用者要處理”, “排程匯入供應商的產品資料格式有誤-供應商的錯”,“網路中斷-喂!網管醒醒”, … 為了強迫包商工程師改變思考習慣, 避免他不分青紅皂白的全部 “try…catch…” 起來傳回同一個錯誤。進而變成有效的下包商驗收準則, 你必須先找出與這系統相關的 “責任區”, 如果Error Code有4碼, 第一碼可以是責任區的代號, 像： 1xxx-代表使用者操作問題 – 像帳號密碼有誤。 2xxx-代表供應商介接系統問題 – 可能是匯入資料格式有誤, 或根本連不到供應商的主機。 3xxx-代表系統基礎環境有問題 – MIS部門要check是否磁碟已滿, 或網路設備異常。其它三碼則由下包商工程師自行編排分類。相信我, 這時間花的值得, 這樣工程師在寫程式時就會試著去判斷問題的原因, 發生錯誤時, 你手下可憐的維運團隊也不需要再推敲追查半天, 你也不需要無助的找大老闆坐鎮, 來開那種永遠沒結果的跨部門推責大會。另外, 當程式歸責錯誤時, 也可以明確指出是程式 “defect”, 要求下包商修正。下包商再也沒有理由說 “這個是新需求, 要再算錢!”。三、法則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、案件代號、發生時間、輸入資料等資訊, 以便連結到特定客訴使用者行為, 或進行錯誤類型的統計。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.87.162.162