「本文已取得原作者同意转录」 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