CRM 对接：为什么半年后会坏掉，又该如何察觉

对接很少在交付当天出问题。它往往在三个月、半年、九个月之后坏掉——那时大家都忘了它，也没人再去检查。而且坏得毫无声响：页面能打开、CRM 正常、没有报错，只是部分数据不再送达。

下面是四种典型原因。它们有一个共同点：对接自己始终认为一切正常。

CRM 对接为什么会坏：对方改了字段

有人在 CRM 里加了一个必填字段、重命名了某个阶段、改了状态列表。对人来说这只是一个小设置，对对接来说却是契约变更。它仍按旧格式发送数据，接收方要么拒收，要么把不认识的部分悄悄丢掉。

必填字段这种情况尤其难受：商机不再被创建，而错误信息进了没人看的对接日志。有一段时间，销售还以为只是客户变少了。

访问凭证过期或被更换

令牌不会永远有效。有的服务签发一年，有的在管理员改密码时作废，还有的在「当初用谁的账号配置的」那位员工离职时失效。

此时对接会收到拒绝访问，而多数实现只是跳过本轮：数据没发出去，一小时后再试，如此循环。外部看到的症状是数据先「延迟」，然后干脆不再出现。

定一条规矩：对接必须跑在独立的服务账号下，而不是某个人的账号下。否则第一次休假或离职就会变成事故。

数据量涨上来了

按每天一百个商机写的对接，未必扛得住一千个。它撞上的通常不是速度，而是限制：每分钟请求数、单次数据包大小、响应超时。

一旦超限，外部服务要么拒绝，要么直接断开连接。如果代码里没有重试，部分数据就会静默丢失。这个问题的特征是丢失会「游走」：今天这批没到，明天那批没到，彼此毫无关联。

业务流程变了，却没人动对接

这是最常见、也最让人无奈的原因。团队换了跟进方式：加了一个阶段、改了分配规则、客户录入方式也变了。对接仍在执行半年前商定的逻辑——从代码角度看它完全健康，只是它做的事已经和人的做法对不上了。

技术上这里没什么可修的。唯一的解法是：流程变更时有人会想起这些对接——也就是说，对接必须有明确的负责人。

怎样做出会自己报告故障的对接

脆弱的对接与可靠的对接，差别不在代码质量，而在有没有反馈机制。下单时至少应当要求这几项。

• 静默告警：平时每天有几十条数据，某一天一条都没有，系统就该通知人。这一条能抓住大多数故障。
• 网络错误自动重试，并在重试用尽时单独发出通知。
• 定期核对：每天比对两侧的记录数量，出现差异就上报。
• 通知要发到有人会看的地方：即时通讯，而不是服务器上的日志文件。

今天就能做的自查

• 上一次有数据通过它是什么时候？如果你不知道去哪儿看，这本身就是答案。
• 比较两侧昨天的记录数量，差值应当为零。
• 查清它跑在谁的账号下。如果是某位员工的账号，就该安排迁移到服务账号。
• 问一句：如果外部服务连续三小时不可用会怎样。对「数据之后会补上」这个回答，要实测验证。

对接不是一次性的工程，而是基础设施的一部分。它需要的不是频繁维护，而是「出问题时能开口说一声」的能力。没有这个能力，故障最终会由客户告诉你，而且方式通常很不愉快。