早上打开后台的那一刻就知道不对劲一整夜的咨询一条自动回复都没有买家的消息静静躺在列表里。自动回复「全停」和「偶发漏答」是两种问题——偶发漏答多半是词表的事全停基本是链路断了。排查顺序很重要从外到内、从整体到局部五步之内一般能定位。## 检查点一账号本身是不是正常的先从聊天账号查起因为这一层出问题的比例不低而且症状和「全停」几乎一样。**登录状态。**账号是不是被挤下线了、是不是提示需要重新登录、有没有安全提示。桌面端挂着的同时又在手机端登录很容易把桌面端挤掉而桌面端恰好是自动回复在跑的地方。**账号限制。**近期是否收到过平台的功能限制通知。受限之后消息收发会静默失败表现和「自动回复失灵」一模一样。**判断方式很直接用另一个号给这个号发一条测试消息看消息本身能不能正常收到。能收到消息、但没有自动回复说明账号没问题问题在后面几个检查点连消息都收不到先解决账号。## 检查点二网络与设备网络。**看设备是否连着网、有没有切到需要验证的网络、是否处于断网重连状态。网络抖动会导致消息收得到、回复发不出去这时后台会堆一批「已触发未发送」的记录。**设备状态。**是不是休眠了、屏幕锁了、笔记本合盖了某些系统在休眠时会挂起后台进程。判断方式是看事件日志里最后一条成功回复的时间如果那个时间点正好和关电脑、换网络的时间对得上方向就明确了。## 检查点三进程和客户端还在不在跑这一层查的是「软件是否活着」。**进程状态。**客户端是否还在运行、是不是被系统清理掉了、有没有卡在启动界面。**后台权限。**有些系统会限制后台运行长时间无人操作后自动冻结进程需要把相关权限放开。**有个省事的判断方法让客户端主动发一条心跳或测试消息。**能发出来说明进程活着发不出来重启客户端起来之后立刻用测试消息验一条回复确认恢复。## 检查点四规则开关与时段前面三层都正常就该怀疑配置了。这类「全停」往往是自己的操作造成的。**总开关。**自动回复是否被整体停用了改规则时误关总开关是相当常见的一种事故。**时段规则。**当前时间是不是落在「休息中」或者节假日档里换成节假日口径后忘了切回来第二天的表现就是全停。**规则优先级。**新加了一条宽泛规则把原有规则全都压住了表面上也是「原来的回复都不见了」。这一层的判定标准是看触发日志如果日志显示消息进来了、但没有命中任何规则问题在规则层如果连日志都没写说明请求根本没到系统回到检查点二。## 检查点五额度、授权与到期最后一层是账号级的授权状态。**授权是否过期。**登录凭证过期后系统会停止工作但并不一定弹窗提醒。**额度是否用尽。按量计费或带额度上限的方案额度耗尽后会进入降级状态——常见的降级方式是只记录不回复。服务是否到期。订阅到期、试用结束同样会停。这一类问题的特点是恢复之后要补的动作比较多额度用尽期间收到的消息不会自动回补需要导出这段时间的会话人工跟一遍同时对有紧急时效要求的买家单独联系。## 恢复之后做三件事一、补接待。**把停机时段的会话按时间顺序过一遍先处理有明确时效的已付款未发货、售后超时。**二、定责与复盘。**记清楚停机起止时间、根因落在哪一层写进记录下次同类问题直接跳到对应检查点省掉一遍从外到内的排查。**三、加告警。**这是把「下次还要靠人发现」变成「系统自己喊人」的一步至少配三条告警——进程掉线、额度剩余不足、连续一段时间没有成功回复。三条告警配齐多数全停事故能在几分钟内被发现而不是等到早上开门。## 小结全停排查的顺序是账号、网络设备、进程、规则时段、额度授权从外到内一层层排除。多数问题落在账号、进程或时段设置这三处。修好只是及格把补接待、复盘和告警三件事做完才算把这次事故变成了资产。## 参考文章- 自动回复上线前的验收测试- 微信回复超时与重试怎么处理