5个案例。
1、400状态码
有次在发版验证环节,小哥哥发现自己的账号无法登录。叫来了其他测试人员,他们的登录都没有问题。我当时有说:我看报错是400错误,就是客户端请求非法。这种错误一般是请求时cookie或者其他参数有问题造成的,应该不是服务问题。
小哥哥还是比较担心,我就等着他验证。他用账号在手机端登录也没问题。其他人登录也没问题。甚至将有问题的账号发给其他人登录也没有问题。他才放心继续发布。
晚上的时候,我突然想到:是不是cookie的值被改坏了。建议小哥哥清理一下缓存和cookie。小哥哥说采用无痕浏览就可以正常登录了。
总结:400问题一般不用惊慌。之前我们还遇到过,我们自己发布,灰度中有一些调用方调用到灰度的机器,就报400错误。非常确定的因果:我们发布引起了调用方错误。结果我们没有回退。只是暂停继续发布调查原因。后来确认调用方的调用方式不是特别规范,我们升级了httpclient的版本,导致校验加强,他们就报错了。处理方式是我们等调用方修改完成后继续发布。
2、502状态码
这个开发人员可能会比较熟悉。遇到这个问题,很可能服务在重启,稍等一下就好。
3、503状态码
之前遇到过几次,遇到后大家的第一反应是回滚发布过的服务。实际上如果服务的日志是正常的。回滚应该不起作用。如果发布的内容是个别接口的变更,不会引起503服务不可用错误。接口有问题是500内部服务出错。
遇到的几次,有一些是我们在本地调试,修改了service的yaml文件,还有一些情况是运维那边做了修改导致问题。
总结:出现这个错误应该是全局的修改,不是自己改坏一个接口就可以达到的效果。
4、499状态码
这个状态码一般不是应该服务器产生的。nginx等代理服务器会在自己没有收到请求的响应时包装一个499错误,就是响应结果为空。这可能意味着请求超时了,或者连接被中断。排查这个问题可以从响应耗时长先排查,不行可以通过网络抓包来排查。
5、404状态码
这个就比较好办了。地址错误或者不存在。