web

记录一次线上问题排查

Posted by wml on July 10, 2018

说在前面

(writed 2020/07/11-modified 2020/09/14) 程序猿最怕的是什么,404 not found?不,我觉得最令人头秃的难道不是开发、测试环境一路顺畅,开心地一上线,结果就报错了==而且还是一些奇怪的错误??

要上线了(^▽^)

一个夜黑风格一如往常的发版日(就是晚上8点…),在大家奋战开发了几天后,终于迎来了可喜可贺的上线时光,大家怀揣着激动而又紧张的心情摩拳擦掌,等待迎接胜利的曙光(✪ω✪)

作为前端开发er,这种场面自然是见过不少了,一种运筹帷幄之中,决胜千里之外之外的自信让我非常淡定坦然地等待着测试宣告前端的成功部署。

部署成功了?。。

“部署成功,现在开始回归测试”随着测试一声令下,我赶紧打开了页面准备查看,结果赫然引入眼帘的是一片空白,和右下角醒目的错误提示!!!∑(゚Д゚ノ)ノ

img1

多刷新几次以后,页面是出来了,但。。这这丑陋的页面是怎么回事?

img1

什么情况?这什么错误?测试、本地都正常啊,仔细看着错误提示,是说refuseed apply style,是了,样式挂掉了,还好还好。。

排查过程

但,样式为什么会挂呢?后面提示是说MIME Type(text/html)不支持stylesheet MIME Tyle,关于MIME Type简单描述下,这里就不深入了,如有兴趣可查阅相关文档:

MIME Type是用于描述消息内容类型的标准,简单来说就是浏览器用来区分消息内容用什么形式显示,是html还是gif还是css等。。是资源的媒体类型,通过Content-Type表示;现代浏览器都缺省设置了标准的常见的MIME类型,会自动识别内容的类型,即内容嗅探

赶紧查看样式文件里头部响应,果不其然

img1

这样式被识别成了html文件,样式当然会挂了;另外,发现一个X-Content-Type-Options: nosniff的响应表头;对于这个响应头相对陌生,查阅资料发现:

如果服务器发送X-Content-Type-Options: nosniff响应头,则script和styleSheet会拒绝包含错误的MIME Type的响应,是一种安全功能,防止MIME类型混淆的攻击,以此过滤不安全的文件。

简单说就是,加了这个响应头以后,上文提到的浏览器会自动对内容进行嗅探的功能则会被禁用,除非style和script的MIME类型是对应的text/css或者application/javascript

问题很明显了,这个文件的MIME Type错了,找到了问题所在,就是查找为什么会出现这个问题以及解决问题了(o゚▽゚)o (道理我都懂系列==)。

解决问题啊。。

为何会出现这个问题?如何解决?先从自己入手,就像前面说的,常见的媒体类型不需要设置,浏览器会自动识别,样式文件前端一般不会去设置content-type;那nosniff的头部信息基本可以确定是服务端返回的,由于公司业务分工问题,服务器资源配置等一系列问题由专门部门(ops)负责。

正要咨询时,测试小伙伴抛出一个业务问题,我:???测试er页面没问题?验证后确实正常==当前业务有两台服务器,这个情况也就意味着,难道只有其中一台服务器出了问题??

带着这个疑问还是得请教ops大佬,抛出问题:其中一台服务器有问题,响应头的content-type错了,而且还不允许浏览器嗅探,请求查看服务器的配置是否异常?ops反馈服务器配置是一样的,通过摘除单台服务器进行测试后,定位到出问题的服务器,查看该样式表的头部返回信息确实有问题,但ops反馈头部信息是客户端提供,很显然,静态资源文件正常不会设置头部信息==事情仿佛又回到原点。。找到错误但不知道为什么抛出这个错误,自然也无从下手解决。

img1

随着时间一点点流逝,为了节约时间,只能让测试大佬们先将就着可用的服务器把业务代码回归测试一遍,自己再一一排查,在前端肯定没有设置头部信息的前提下,理论上css样式浏览器肯定是能自动识别的,现在不能识别,无非就是服务端“有意无意”地设置了头部信息,循着这个思路,再次查看报错的文件,直接访问该样式文件,发现竟然出现了302重定向!

img1

而且是重定向到了首页,再次验证正常服务器上的首页响应信息

img1

一样是携带了X-Content-Type-Options: nosniff的信息!在查阅相关资料时有发现,一些较新的服务器框架会在响应文件中加入该参数。那访问这个样式为何出现重定向,该服务器上是否存在这个文件?因为都是走的一套打包部署脚本,其中一台服务器是可用的,所以一直没往文件可能丢失方面想,若真的存在这种文件丢失的情况,找不到该文件重定向回首页也是可能的。带着这个猜测咨询了ops帮忙验证,给的出结果和猜测一致!正常的服务器上,css文件的响应是正常的,出问题的机器上,样式文件直接被重定向了,在该服务器上也确实不存在该文件!

img1

img1

终于定位到问题了!后续对该服务器重新部署添加了文件后页面样式终于正常了!

完结。。

等问题处理完成已经是晚上11点了,问题的解决虽然简单,但是排查问题的过程却是很坎坷,另外由于已经是下班时间,沟通成本也基本翻倍==再加上自身技术不够硬,很多一眼能看出来的问题也花了许多时间,也发现了很多自身的不足:

1、网络知识还不够扎实,对于浏览器对文件的渲染其实本质上还是不够了解,例如关于浏览器的嗅探技术一直以理所当然的态度接受,并没有去真正了解原由;

2、服务器知识薄弱,虽然业务中较少接触,但实际开发上线中,少不了要与其打交道,作为一个优秀的前端er,至少需要能快速定位到问题所在,而不是临阵磨枪。。==