【项目实战-12】排查12小时，竟是CLB安全组没打开

【摘要】

案例：程序逻辑在没有任何变更的情况下，研发耗费了12小时（20200610 02:00 ~ 20200610 14:00) 排查登录接口耗时长的问题。此案例提供了腾讯云上全链路（ecdn->waf->clb->ngnix->业务方后台）的排查思路： 简化链路，逐环节排查。

【问题表现】

合作方APP，准备提交苹果审核的时候，发现登录接口会卡很长时间，然后就报错。

【问题分析与排查思路】

1. 首先排查业务方后台，这个对开发而言是最容易的。

【20200610 02:00】首先怀疑接口参数不正确，因为DB最近一直在做数据迁移，代码可能没有同步。

 开发检查了业务逻辑代码，并未发现明显异常问题。

【20200610 03:00】排查redis。发现redis中的token不存在，怀疑redis爆满问题。

 清空redis,并重启redis读写实例，问题没有改善。

【20200610 11:13】分析业务日志，确实有耗时长的问题，但无从分析。

token获取不到的响应包如下：

{"accessToken":null,"identityToken":null,"tokenType":null,"refreshToken":null,"error":"invalid_grant","expiresIn":0}

接口调用无论是成功还是失败，耗时都比较短。重新设置超时为3秒，发现耗时不稳定：一半请求是300ms，一半请求是3秒。

2. 怀疑链路有问题，进行全链路排查：ecdn -> waf -> clb -> nginx

首先怀疑ecdn。运营同学把ecdn切换到专用链路，问题没有解决。

去掉ecdn，耗时现象依然存在。

把域名直接cname到waf的域名，绕过ecdn。发现延时并没有改善。从日志来看，存在请求时间3秒左右的情况，概率还很高。

抓包分析，源站确实存在3秒回包的现象

分析WAF，发现某个回源IP（106.55.175.62:443）有不少连接超时。

该回源IP对应的是一个CLB，所以去看看CLB是否有异常。

入站做了限制。从操作记录来看，是昨晚做压测的时候没有去掉，具体时间是昨晚10:43分开始。

【总结】

1. 收敛权限：无关人员账号已完成清理，并把控制台写操作日志拉出来做一个变更大盘。
2. 更高效的排方式： 后类似问题再出现时，寻找最短恢复路径，可以按照业务访问路径端到端一段一段的，逐步缩小问题。