Welcome to Alex's Midway

CDN缓存不同步:一次线上调试的经历

August 31, 2019


写在前面

这是大概3个月之前的一次线上调试过程,最后排查到的原因很简单,但调试过程让我认识了所谓“线上环境复杂”是什么意思。

背景信息

这是入职后接手的第一个H5页面需求,也是比较重要内部项目,几乎所有公司部门都参与了此项目。项目完成后获得了公司的内部奖励,当然这是后话了。

我负责的部分算项目中比较简单的一块,2个web管理后台页面+5个H5前端页面。管理后台录入数据,然后H5页面拉接口展示,同时后台数据还可以被客户端直接使用。主要工作量在我的后台搭档那里,前端切图仔按设计出页面就可以了。

活很简单,慢悠悠的一周就做完了,然后自测、提测。PM说需要等下游客户端开发完毕后一起发布,于是等了快3周。

到了发布当天,却出现了莫名其妙的样式bug。

BUG排查过程

发布后搭档的手机发现有一个H5页面样式全崩了。而我手机上的显示却完全正常

  1. 检查发布过程

    gitlab里CI打包正常-->重新发布-->发现问题依旧

    结论1:暂无

  2. 清理App缓存,再刷新页面

    因为App里有页面缓存,加上之前做过预发布,我这里显示正常有可能是之前的缓存。那么首先清理掉缓存,确保页面文件都是新发布的。

    清理后,搭档的手机显示仍然不对,我的手机显示也不对了。

    结论2:应该是css文件有问题

  3. PC端查看

    这个页面是H5和PC端共用的,所以PC端也可以查看,这样调试成本稍微低一些。

    首先,PC端也显示不正常-->用Chrome devtool看css文件是否有正确下载-->未见下载css文件

    结论3:css文件没有下载

  4. 排查CI发布包文件

    发现发布包html文件中没有引入css文件-->发现html文件因为代码格式化引发打包程序bug,未能正确打包css文件

    结论4:css文件没有正确打包

  5. PC端查看,发现css文件有错误

    修复后重新发布,bug依然存在-->浏览器devtool在network里能看到对应的css文件-->打开css文件路径,查看css文件内容是否正确-->经过关键词搜索,发现缺失了几个样式

    结论5:css文件有错误

  6. 下载gitlab打包文件,比对线上和发布包内的css文件

    发现打包的css文件和线上css文件hash不同,似乎发布未生效。

    结论6:发布的css文件与线上css文件不同步

  7. 偶然:另一名同事发现手机显示正常

    另一名同事清理App缓存后显示正常-->我和搭档的手机显示仍然不对,PC端也不对

    结论7:css文件在某些手机上正常下载??!!!

  8. 切换为同一网络条件

    注意到搭档和我都连接的公司wifi,而另一名同事用的移动4G,难道是CDN缓存未同步?

    让另一名同事连公司wifi,清理缓存-->刷新页面,样式bug复现

    结论8:CDN缓存不同步??

  9. 增加vConsole,比较显示为正常的css文件和有问题的css文件

    临时上线增加了vConsole的版本,在另一个同事手机上查看css文件版本-->正常显示的css文件hash和异常css文件hash不同-->前者和gitlab发布包内css文件hash相同,后者和上一个发布版本的css文件hash相同

    结论9:确认CDN缓存不同步

  10. 修复上线

    出问题的css文件做了小改动,刷新了文件hash,再次发布上线,bug立刻修复

整个调试排查时间约3个小时

原因分析

第一次bug是打包的失误,第二次bug复现应该算是典型的CDN缓存问题。

因为html文件使用相同名字,覆盖发布,可能会有缓存同步延迟,而css文件名是基于hash的,每次改动后文件名不同,不存在覆盖问题。

所以真正的bug源就是html页面文件没有同步,导致访问时没有请求到新版的css文件。第一次bug出现时,css文件没有下载可以理解,因为打包遗漏了,自然不会下载。但是第二次bug出现时,合理的组合应该是新html+无css或者新html+新css

为什么会出现 新html+旧css这样的组合,暂时没有合理的答案。因为当时着急发布,没有立即检查修复后的情况,现在已经无法还原场景了。哎。

总结

总之失误挺多的,经验不足也导致反应不够迅速,处置手段也比较具有侵入性。比如,老司机估计最多在第4步就判断出原因了,而我这只菜鸡在第6步才意识到。第9步也完全可以省去一次发布,用4G网络开个热点通过PC端调试即可。

技术进阶之路漫漫,我还要继续努力。