您的位置 首页 Life | 生活

被诡异bug困扰的日日夜夜纪实

前几天被一个生产环境的bug给折磨的有些喘不过气,一来他非常随机,只有部分用户碰到,也没办法在本地重现,二来hard deadline没有几天了,roll back呢,怕是要赶不上deadline。不roll back呢,修复又毫无头绪。

更尴尬的是,这是我进公司搞的第一个项目,而且我就是总负责。人脉么人脉还没建立,公司的知识体系么还不是那么系统,正当需要靠项目立威之时,碰到这么一个问题,压力可谓巨大。

事件流程?

项目需要做一个SSO的升级,从其他的验证方式升级到OpenID,前后端都搞定并release之后,一部分用户突然报告infinite loop,无法完成认证进入程序。奇怪的是工程团队的人员都没办法重现这个问题,而且用户中也只有一部分人有这个问题,更诡异的是,这个问题是间歇性的。

我们收集到了一些断断续续的数据,得出以下线索:

线索一:一开始的时候,发现问题都发生在windows机器上,并且都用的chrome, 这让我很疑惑,chrome的解释差异不应该分mac和windows呀?查了下release note,发现的确在这个时间点chrome在windows上发布了新版本!

线索二:infinite loop之前在测试的时候发生过,是由于load balancer上没有设置stickiness cookie,导致多服务器的情况下,session不能准确的传递到使用中的服务器。所以,我的关注点又放在的load balancer上,也许在一定的环境情况下,load balancer的stickiness cookie会失效?

线索三:我们的解决方案是使用apache上的mod_auth_openidc这个组件,我找到了其他同样用这个架构的团队,然而他们近期上线的功能并没有遇到和类似的问题,整个公司中只有我和另一个团队遇到了相似的问题,于是我们在想是否是因为配置差异导致了问题。

找到了遇到相同问题的团队,稍微放宽了点心,至少这个问题存在普遍性,但又不是完全普遍,这也让我们十分困惑。由于是偶发事件,我们2个团队再次确认了没有一个工程人员可以重现问题。我们从周三一直到排查到了第二个周一,从chrome开始排查,再到AWS的ELB,最后只剩下了apache配置问题。

一直不能重现问题,让我们十分迷茫,因为即使找到了正确的配置,也不能确认是否解决了问题,总不能一直往生产环境去推版本,再让用户当小老鼠吧?

既然已经排除掉了其他原因,我们全力的focus在的apache的配置上,奈何我们没有一个是这方面的专家,只好重新拿出了mod_auth_openidc的文档一条条阅读,一点点去理解他的工作原理。功夫不负有心人,在理解原理后,不断的尝试破坏,终于重现了问题,问题一重现我们就找到了解决方案,因为这个问题的确挺蠢的。

问题所在

解释问题之前,我们先了解下mod_auth_openidc的工作机制:

  1. 客户端发送请求给服务器,服务器接收到请求之后给客户端一个临时的session cookie,我们叫他为state cookie
  2. 客户端拿着这个临时的state cookie去验证中心进行验证,验证结束,拿着这个state cookie到服务器进行比对验证
  3. 如果验证通过,服务器会删除这个state cookie然后给一个永久的session cookie
  4. 客户端使用这个永久的session cookie进行通讯验证

问题就出在了这个永久的session cookie上,经过反复验证我们可以顺利的从服务器拿到这个session cookie,但是拥有这个session cookie我们依旧会被服务器分配state cookie并且无限的跳转到验证中心页面,从而重复的在:生成state cookie -> 转换到 session cookie -> 生成新的state cookie -> 再覆盖之前的session cookie上。

既然问题找到了,那么是什么原因呢?

我们发现,这是因为,服务器根本没有拿刚生成的session cookie来验证!而是使用了其他的session cookie导致了验证一直无法通过。如下方式可以重现问题:

  1. 在A产品(a.xxx.com)上进行了OpenID的验证,得到了session cookie,但是A产品将session cookie的域名设置成了顶级域名:xxx.com而不是a.xxx.com
  2. 在到B产品(b.xxx.com)上进行验证,出现了无限循环,原因是B产品的session cookie使用的域名是子域名b.xxx.com

问题简单的来说,就是当有2个OpenID的session cookie时,服务器优先使用顶级域名的进行验证,而正好产品A错误的使用的顶级域名,导致我们使用准确域名的产品没办法得到验证。

也就是说,之所以我们不能重现问题,是因为我们没有使用“有问题”的产品A,得不到问题的cookie!

解决方案也应运而生:单独给我们的session cookie取个名字即可,域名再变都没事。

真相大白,真的吐血。

后续的思考

从技术角度来讲,这是一个非常低级的错误,但是也是在我们控制范围之外的,我们使用了严格的子域名来限制cookie,但一旦有团队使用了更广的设置,就会造成问题。这个问题不仅仅是影响我们团队,其实会影响到公司所有使用OpenID的团队,之所以我们碰到了,是恰巧我们的用户同时在使用“问题”产品。

修复问题之后,我也像mod_auth_openidc官方发了封信,希望这个问题能够从源头得以解决,虽然主域名优先级高没什么问题,但是应该优先验证request进来的域名,最坏也是验证所有子域名和主域名的cookie。最差的情况,也应该在域名设置的时候,给一个强烈提醒和best practices。

从技术角度来说,前端真的好复杂好麻烦,各种细节上的问题处理不当,都会埋下危险的伏笔。而这次正好是前端+DevOps服务器配置,让一个不是那么专业的人研究真的挺为难的。现在的大趋势就是Dev和Ops大融合,但这样真的好么?如果没有特别专业的认识把控,这种配置的问题又如何避免呢?

从团队角度来说,我现在慢慢理解了很多工程师一个级别一呆就是一辈子,总有一个级别薪资和责任是相对来说平衡的,再往上走要担待更多的责任,薪水并不一定成正比例的增长。越往上走,遇到问题也会越无力,本来可以依靠着更高级别的人帮你解决,但是随着你的级别提升,能帮助你的人越来越少,需要依赖你的人却越来越多。

但是不往上走,怎么通过决策来实现自我呢?

看完了?留个评分呗?
[5人评了分,平均: 4.8/5]

本站原创文章皆遵循“署名-非商业性使用-相同方式共享 3.0 (CC BY-NC-SA 3.0)”。转载请保留以下标注:

原文来源:《被诡异bug困扰的日日夜夜纪实》

发表评论

邮箱地址不会被公开。

评论列表(2)

返回顶部