云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic
三、法则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、案件代号、发生时间、输入数据等信息, 以便链接到特定客诉用户行为, 或进行错误类型的统计。
