解决问题时的短路问题

场景描述 #

前一阵子做企业微信的组织和人员同步，上线后本来是风平浪静，直到接到一个工单：有家企业的部分员工的部门信息没有同步过去。

工单描述的有点模糊，所以我登上跳板机查询这家企业和给到的员工的信息，确定了问题：部门已经同步过去，员工也已经同步过去，但是员工的所属部门没有同步过去。

解决问题的心路历程 #

找到了问题，先进行“路径分析”。既然是同步问题，那么问题就可能出现在：

1. 数据源：企业微信给的数据会不会有问题？
2. 同步逻辑：整个同步逻辑还是比较复杂的，是不是最近某些业务功能的代码，导致了部门字段没有正确同步？
3. 目的服务故障：拼接好数据后需要向员工服务发送更新请求，是不是目的服务出现了问题？

首先根据日志，能够查看到向员工服务发送的请求数据缺失了部门字段，因此排除目的服务故障的可能。

再思考获取的数据源数据有问题？但是这块的日志没有记录，因此不能确定。所以只能先看同步逻辑会不会有问题。

通过对相关代码逐行查看，并没有发现存在逻辑问题，当然这不能说明代码就没问题，尤其在大部分代码是我自己写的情况下。人往往会忽视自己的某些问题，尤其是自身逻辑本就存在问题时。

这时解决这个问题已经花了两三个小时，而且这也不是一个很严重的问题。正好今天有版本，把企业微信返回的数据记下日志应该就能确定问题了，我如是想。

找到解决方案时想一想还有没有更好的解决方案。我们往往在找到一个解决方案时就停止了思考，就像电路短路了一样，绕过了电阻（问题）。

正当我回复工单时，老大过来问了下问题的进展，于是我把思路和解决办法简单的说了下，老大提议为什么不让运维帮忙调下线上接口，看看是不是企业微信的数据源问题。这真是个好提议。但是为什么我没想到？可能是代码写的太好，所以很少需要这种解决方式；可能是脑子“短路”了，已经不想理这个问题了；也可能是性格问题，不想麻烦别人。

让我们继续！

获取到企业微信的数据后，发现数据“没问题”，那个部门id赫然就在响应的json中。。。

于是我又开始逐行看代码，当然这时是老大和我一起看。又经过一番的推理以及自说自话，发现代码还是没问题。。。

难道是刚才的眼花了，企业微信给的数据是有问题的？所以我们又去确认了一番，这一看还真有问题。

过去的经验并不总是有益的，有时它能造成我们大脑中的盲点。

这个接口的返回值包含一下几个字段（接口地址为https://work.weixin.qq.com/api/doc/90000/90135/90196）

{
	"department":[60], # 所属部门列表，每个元素都是部门id
	"is_leader_in_dept": [0], # 所属元素与department一一对应，1为是对应的部门leader，不是为0
	"main_department": 60 # 主部门id
}

按照我们的经验来看，main_department应该是非空字段（虽然受到权限限制，但是我们属于内部开发，肯定有权限），我们在平时的开发和测试中也没有发现员工没有主部门的情况。而当时接口的返回值是这样的：

{
	"department":[60], 
	"is_leader_in_dept": [0]
}

是的，没有main_department！所以员工的部门身份没有同步过去！我们上次看到了department里边有部门id，就潜意识认为企业微信返回的员工信息是没问题的！

最后 #

虽然找到了问题，但是浪费了大半个下午的时间，还是有点可惜的。那么为什么会花费这么多时间呢？总结下此次“事故”的解决办法：

1. 不要盲信权威，即使是腾讯这么大的公司提供的接口也可能是有问题的（当然，不一定是企业微信的接口问题，也可能是我们对字段的理解有问题）
2. 多想想有没有更好的解决方案
3. 不要“迷信”过去的经验