标签：参与 部分 tle 理解 需要 nbsp 进阶之路 同名 通过
这是大概3个月之前的一次线上调试过程，最后排查到的原因很简单，但调试过程让我认识了所谓“线上环境复杂”是什么意思。
这是入职后接手的第一个H5页面需求，也是比较重要内部项目，几乎所有公司部门都参与了此项目。项目完成后获得了公司的内部奖励，当然这是后话了。
我负责的部分算项目中比较简单的一块，2个web管理后台页面+5个H5前端页面。管理后台录入数据，然后H5页面拉接口展示，同时后台数据还可以被客户端直接使用。主要工作量在我的后台搭档那里，前端切图仔按设计出页面就可以了。
活很简单，慢悠悠的一周就做完了，然后自测、提测。PM说需要等下游客户端开发完毕后一起发布，于是等了快3周。
到了发布当天，却出现了莫名其妙的样式bug。
发布后搭档的手机发现有一个H5页面样式全崩了。而我手机上的显示却完全正常
检查发布过程
gitlab里CI打包正常-->重新发布-->发现问题依旧
结论1：暂无
清理App缓存，再刷新页面
因为App里有页面缓存，加上之前做过预发布，我这里显示正常有可能是之前的缓存。那么首先清理掉缓存，确保页面文件都是新发布的。
清理后，搭档的手机显示仍然不对，我的手机显示也不对了。
结论2：应该是css文件有问题
PC端查看
这个页面是H5和PC端共用的，所以PC端也可以查看，这样调试成本稍微低一些。
首先，PC端也显示不正常-->用Chrome devtool看css文件是否有正确下载-->未见下载css文件
结论3：css文件没有下载
排查CI发布包文件
发现发布包html文件中没有引入css文件-->发现html文件因为代码格式化引发打包程序bug，未能正确打包css文件
结论4：css文件没有正确打包
PC端查看，发现css文件有错误
修复后重新发布，bug依然存在-->浏览器devtool在network里能看到对应的css文件-->打开css文件路径，查看css文件内容是否正确-->经过关键词搜索，发现缺失了几个样式
结论5：css文件有错误
下载gitlab打包文件，比对线上和发布包内的css文件
发现打包的css文件和线上css文件hash不同，似乎发布未生效。
结论6：发布的css文件与线上css文件不同步
偶然：另一名同事发现手机显示正常
另一名同事清理App缓存后显示正常-->我和搭档的手机显示仍然不对，PC端也不对
结论7：css文件在某些手机上正常下载？？！！！
切换为同一网络条件
注意到搭档和我都连接的公司wifi，而另一名同事用的移动4G，难道是CDN缓存未同步？
让另一名同事连公司wifi，清理缓存-->刷新页面，样式bug复现
结论8：CDN缓存不同步
增加vConsole，比较显示为正常的css文件和有问题的css文件
临时上线增加了vConsole的版本，在另一个同事手机上查看css文件版本-->正常显示的css文件hash和异常css文件hash不同-->前者和gitlab发布包内css文件hash相同，后者和上一个发布版本的css文件hash相同
结论9：确认CDN缓存不同步
修复上线
出问题的css文件做了小改动，刷新了文件hash，再次发布上线，bug立刻修复
整个调试排查时间约3个小时
第一次bug是打包的失误，第二次bug复现应该算是典型的CDN缓存问题。
因为html文件使用相同名字，覆盖发布，可能会有缓存同步延迟，而css文件名是基于hash的，每次改动后文件名不同，不存在覆盖问题。
所以真正的bug源就是html页面文件没有同步，导致访问时没有请求到新版的css文件。第一次bug出现时，css文件没有下载可以理解，因为打包遗漏了，自然不会下载。但是第二次bug出现时，合理的组合应该是或者。
为什么会出现 这样的组合，暂时没有合理的答案。因为当时着急发布，没有立即检查修复后的情况，现在已经无法还原场景了。哎。
总之失误挺多的，经验不足也导致反应不够迅速，处置手段也比较具有侵入性。比如，老司机估计最多在第4步就判断出原因了，而我这只菜鸡在第6步才意识到。第9步也完全可以省去一次发布，用4G网络开个热点通过PC端调试即可。
技术进阶之路漫漫，我还要继续努力。
标签：参与 部分 tle 理解 需要 nbsp 进阶之路 同名 通过
原文地址：https://www.cnblogs.com/sqlserver-mysql/p/12748816.html
