云工作术
各类应用演示
案例故事
逃离恶梦
关于 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", 要求下包商修正。下包商再也没有理由说 "这个是新需求, 要再算钱!"。
