记一次故障排查经历

项目场景：

       某天，我需要跑批某活动下几十笔数据。

        A,B,C 是内部的三个平台。

        A 平台跑批数据，需要调用 B 平台的接口完成低层业务能力，B 平台需要调用 C 提供的接口完成校验。A 跑批数据传入用户和对应的俩个 itemId 给到 B 平台，但是最终调用结果是用户无 itemId。但是从 C 的管理平台上能查到用户确实拥有了这两笔 itemId 。已经大晚上了，大家都下班了，但是问题没解决，没法定位，无奈，只能找 C 平台的人来定位了。

---

问题描述：

        层层调用，但是某一层业务方出现问题，往上抛的却是一个异常宽泛的原因，作为调用方，我们是完全摸不着头脑，也无法去设计方案解决此类问题。最终只能靠摇人去查他们平台的日志，去定位原因，但是这样只能查单笔请求中失败的原因。

---

原因分析：

        实际错误原因没有抛给调用方，导致调用方无法完成一套正常的业务流程。我们获取到的失败原因实际算是无效原因，实际解决不了问题。经过了解得知 C 平台提供出来的能力是一种通用能力，查询用户名下所有的可用的 itemId，如果对每个失败原因进行组装返回，这就涉及到一个问题，如果用户名下 itemId 超过一定的量，会降低系统性能。

---

解决方案：

        我认为作为内部的三个平台， C 平台完全可以根据是否传入了具体的 itemId 来进行失败原因的组装，如果传了则传达调用方失败原因，如果没传，默认进行查询用户名下所有 itemId 即可，作为调用方确实是有意传入了指定的 itemId 要去使用，如果无法告知失败原因，业务很难进行下去。上层可以决定如果将失败原因展示给用户看，下层不应该自己屏蔽掉失败原因。

        以上是个人意见，感谢各位大佬指教。

mrathena: 浪费人力资源，其实说白了，还是一开始没有打好底子，这种具体信息，真的很有必要一层层传上来的，到底怎么给用户展示，由最上层来决定，下层不应该把这些信息屏蔽。