如何解决商家工作台外化报错文案？

如果你想在系统报错上做些什么，希望这篇总结对你能有些帮助。

问题&挑战

▐  消息“看得懂，但没用”最为致命

举个例子：

类型	真实系统报错	商家视角
无下文	“对不起,权限不足,无法操作” “timeout of 60000ms exceeded”	然后呢？怎么办？
不同原因相同报错	“Network Error” “远端调用失败” “系统异常”	哪里错了？
内部黑话	“此商品未双报, 不涉及平销期校验” “未查询到提报tmc”	什么是双报？什么是平销期？你真的以为我看得懂吗？
乱码	“Content type 'application/x-www-form-urlencoded;charset=UTF-8' not supported” “nested exception is org.***.***.exceptions.***: ### Error querying database. Cause: ERR-CODE: [TDDL-4614]*** ATOM '***_i-8vbfhe0qt”	WHAT？！啥？！

▐  这是一个不能根治的问题，苦的还是运营同学

有些情况我们其实是没办法通过开发发版解决，当出现以上客诉我们的PD可能会找到开发同学改文案。

可能会有以下几种声音——

“不好意思，balabala~~~”

“底层服务的报错不控制在我们这。”

“太多了，太老了，改起来需要时间。”

“今天封网。”

本来是想降低百求率，但总有诸多原因没法第一时间处理，最终还是得运营同学解决

解决方案主要有2个。第一个就是，苦哈哈地逐一答疑。第二个，影响面大了就发公告。

▐  如何解决？

基于以上问题，我们需要解决1个主要需求：「现有报错文案亟需治理，要能看懂且有帮助」

再进一步挖掘，会“衍生”出这一些需求

1. 可运营：可以动态地根据场景进行配置，封网期间亦可操作

2. 可反馈：提示有没有帮助用户说了算，可以反馈意见

3. 发现问题：哪些报错是有问题的，可以快速定位

4. 提前布防：在可预见的报错之上提前配置

方案

▐  调研方案 OneCode

OneCode 是集团内成熟的错误码统一管理工具，可以做到 Code --> Message 的动态映射，同时还集成了美杜莎，支持多语言文案接入。

但相对于我们的需求，此工具能力略显不足

1. 国际服务使用的Code既不完整也不唯一，改造成本恐后端开发同学接受不了（需求都做不完）

2. Code 之上加运营无法实现（因为不唯一）

3. 另外，此系统“好像”长期无人维护了，存在停服风险。

得~，还是自研吧

▐  自研方案分析

做在哪一层

可分2部分

第1部分：可控的文案（静态文案）：后端在日常发版修改即可，另外需要补充一些“相对”唯一的 ErrorCode

第2部分：不可控的文案（来自底层）：需要监控、适配，这个做在前端较合适，根据接口+页面+ErrorCode+文案组合条件优化。

• 数据来源

用于分析的数据主要有「错误Code、错误信息」此部分均可来自于服务接口，基于标准的 Response 这个比较容易达成。

{
  "code": 200,       
  "success": true,
  "message": "xxx",
  "errorCode": "错误码",
  "errorMessage": "错误信息",
  "data": {
    ...
  }
}

因为前期有接入 AEM ，报错数据会自动收集，但有个问题，AEM 自动截取了 errorMessage 的前50个字符，所以，完整的数据需要我们自定义埋点上报。

• 数据消费

有了数据接下来就是“清洗”了，我们选择在 DataWorks 平台完成数据清洗、加工任务、编排，将编排后的任务发布，按日进行周期调度。

最终产出按平台、页面、接口地址、错误Code、错误信息联合拆解的数据集，紧接着回流到我们的系统内用于接下来的数据分析、运营配置。

• 建立运营行为

起初我们期望运营行为与唯一Code强绑定，但由于Code无法做到“唯一”，因此，定义一个「场景」就需要多个参数进行条件组合。

如：

1. 文案：所有的被编译的符号可进行反编译还原。

2. ErrorCode+文案：同样的“Network Error”，无 errorCode 的代表网络不通畅需要检查自己的网络连接，而 errorCode 为“SYSTEM_EXCEPTION”的代表底层调用失败，可以稍后再试。

3. ErrorCode+文案+页面地址：同样的“权限不足”，URL1下需引导申请权限1，URL2下需引导申请权限2。

我们提炼了4个条件可供组合：ErrorCode（绝对匹配）、文案（规则匹配）、页面地址（绝对匹配）、接口地址（绝对匹配）。以此可命中1个或多个报错，在此基础上就可以配置运营行为表达了。

▐  交互方案

• 用户侧

升级前：

升级后：

引导：跳转到SOP文档或打开「页面内引导」

反馈：

嵌入式模式：用于自定义

• 运营侧

错误池：

可以看到以下数据：

1. 系统文案、触发页面、接口、Code：可筛选看不懂的报错

2. 报错次数、报错率：判断影响面，报错次数高&报错率高的case需要优先处理

运营中：

可以看到以下数据：

1. 配置内容：优化文案、匹配规则

2. 效果数据：曝光量、拦截率、用户反馈、帮助率

3. 规则圈选中的错误列表

配置表单：

可配置内容：

1. 处理方式：可做运营中英文文案替换、直接转码、原样输出

2. 匹配规则：条件聚合，包括ErrorCode（绝对匹配）、文案（规则匹配、）、页面地址（绝对匹配）、接口地址（绝对匹配）

3. 运营能力：

1. 1. 4种展示模式：Toast、弹窗、侧边通知、自定义（多用于嵌入式）

   2. 3类运营帮助行为：帮助（可自定义文案亦可关联帮助文档）、引导（可做页面跳转亦可关联流程引导）、反馈（可打开留言板亦可引导至小蜜）

▐  技术方案

此部分仅透出部分内容

• 时序交互

• 客户端流程图

• 类图

成果&展望

▐  发现并解决了一些问题

该系统上线2月有余，目前仅开放了一些高频操作和重要页面的监控，期间已完成了以下几类目标：

类型	举例
报错文案治理 让文案看得懂且有用	“远端调用失败” --(限制页面+接口)--> “第三方服务调用失败，请减少商品搜索数量到100内后再试” “Network Error” --(全局+条件)--> “系统遇到了错误”+增加自我排查方法&引导
系统稳定保障 不兼容发布升级提醒保持前后端匹配	报错包含 “application/x-www-form-urlencoded” --(限制页面+接口+code)--> “版本较低，请刷新页面重试”
暴露看不到的问题 发现&跟踪线上问题	线上接口报错率&报错量双高 --> 暴露以下问题： 接口历史性问题2个 多个已下线接口依然有流量 交互缺陷导致接口异常调用问题2个
重大活动提前布防	双十一禁写公告&报错信息联动：禁写期间接口采用“拒绝服务”的方式，伪跨域，前端服务层兜底返回“Network Error”。提前布防，告知禁写时间和处理办法。

▐  未来进一步能力扩展

将错误&Code的监控升级为接口Code的监控，利用规则圈选出业务流程切面，可尝试在此切面上做进一步探索。

1. 切面按SOP组合，可计算人效

2. 切面可注册「引导、问卷」等运营能力

团队介绍

天猫国际前端团队，深耕技术革新，紧密联结业务脉搏，致力于搭建桥梁连接消费者与未来，通过不断优化的全链路体验，创造性地打造下一代人机交互产品。在追求技术极致简洁、高效卓越、灵活多变及新鲜前沿的同时，我们为天猫国际的持续创新和繁荣发展提供坚实的赋能支持。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法