雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
一、魔鬼降臨
在總裁一句 "人事凍結" 的命令下, 身為一間大企業的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", 要求下包商修正。下包商再也沒有理由說 "這個是新需求, 要再算錢!"。
