1.1. 一个空白页面怎么定位?
这个问题很有意思, 就经验来说, 如果页面完全一片空白. 极有可能是后端出现问题, 并且禁用了错误输出. 比如 apache2, 后端配置无错误输出, 并且服务状态 500, 这个时候页面就是一片空白.
如果是前端导致的, 那么极有可能是单页应用异常, 因为普通的 html 输出, 哪怕出了一些错误, 也不太可能一片空白.
排查步骤如下:
1, 打开能看到源码和 request,response 的浏览器, 如 Chrome, 查看源码输出, 如果做不到, 那么使用局域网数据监控软件查看页面输出. 查看源码是否有异常, http 状态等, 本步骤用于检查具体是后端还是前端问题, 还是网络问题.
2, 如果是后端问题, 那么后端查看 accesslog, 程序日志, 看看是否有问题
3, 如果是前端问题, 那么根据给出的 JS 异常之类的排查
1, 先确保网络连接通畅.
2, 查看网络 url 地址是否输入有误.
3, 打开控制台 console 查看报错信息 JS 代码.
4, 查看接口访问是否有请求.
5, 查看路由是否有 path 或者 name 的错误, 导致加载了不存在的页面.
网页加载慢, 有哪些原因?
1. 带宽不足, 首先想到的就是自己网速的问题, 但是一般网速在 1M 以上的, 打开网页一般不会是很慢的. 网站服务器的带宽不够的话, 当大量用户访问的时候, 网页的加载也是很慢的, 这就是网络的出口端和入口端两个方面
2 硬件配置低, 本机的配置也会是一方面的, 但是只要不是老赛扬单核 + 512M 的配置, 一般不会是电脑配置的问题. 服务器端的配置也是同样的道理.
3 CPU 或者是内存被占满的时候, 打开网页很是会很慢的, 因为整个电脑都很慢
4 DNS 解析慢, 域名的解析是需要专门的域名解析服务器来完成的, DNS 解析包括往复解析的次数及每次解析所花费的时间, 它们两者的积即是 DNS 解析所耗费的总时间, 在 http 请求的过程中, 域名解析和建立连接占的时间很多.
5 JS 阻塞请求, 写的 JS 代码出现问题, 解析就会花费很长时间, 这两个 JS 请求之间会出现一个很大的空隙, 就会导致这段时间的资源加载都被阻塞住,
6 接受数据时间过长, http 请求的大部分时间应该花在后面几个阶段, 比如等待响应和接收数据. 但是, 如果接收数据的时间太长了, 长到数百毫秒甚至以秒计算的时候, 那也是有问题的. 这种情况一般是因为下载的内容太重了, 例如大图片, 大脚本等. 这类问题可以使用 GZIP 压缩, 图片压缩或者 JS/CSS 的 minify 等手段来解决.
7 加载某个资源太慢, 如果某个请求比其他的请求多出很多的时间, 那么一般情况就是某个资源的加载太慢, 导致了整个网页变慢, 原因有可能是 1) 资源在第三方站点上, 他们很慢; 2) 这个资源太大了; 3) 这个资源使用的域名有问题
8 后端代码问题, 主要有代码冗余, 数据库发生锁死, 动态请求时间过长等, 这就需要 RD 优化一切可以优化的东西了
9 前端页面请求的资源过多, onload 之前如果有几百行, 速度自然会慢的, 如果请求的资源不存在, 那么速度将会更慢
10 网页本身中包含了追踪或者是分析用户的工具, 从而导致网页的加载时间变的慢, 比如之前海盗湾中会给用户的电脑插入挖矿的 JS 脚本
如何定位 BUG?
用户层面问题指的是用户自己的环境问题或者操作问题, 比如环境不通, 或者操作不正确. 这种问题一般不是 bug, 当然, 如果要考虑构建更加健壮的软件, 那么可以根据实际情况来决定要不要处理这类问题.
到第二步, 用户在 web 页面进行正常操作时, 也可能会发现问题. 这类问题一般通过观察以及利用一些常识可以发现, 比如样式问题一般是 CSS 的问题, 交互问题一般是 JS 的问题, 文本问题一般是 HTML 的问题 (当然有可能是其他问题, 例如 JS 生成 HTML).
到第三步, Web 页面操作后, 比如发出一个请求, 可能会进入中间件这个层面. 我这里说的中间件是广义上的, 比如 LVS,CDN, 各种缓存服务器等等. 我们遇到过一个问题, 发现刚刚上传的图片进行读取展示时就读不到, 那么可以想到可能是负载均衡时将上传照片和读取照片两个请求分配到了不同的服务器导致的, 也就是我们常说的会话保持. 当然, 中间件问题有时候是和开发相关的, 有时候是公司其他团队负责的, 比如 360 公司就是 OPS 在负责. 当然, 中间件也不仅仅会出现在这一步, 实际的项目中可能还会用到更多的基础设施, 比如消息中间件, 数据存取中间件等, 如果发现了相应的问题也就需要有对应的思路去排查.
接着再往下到第四步, 服务会转发到我们真正的后端服务层, Web 服务器, 应用服务器比如 nginx,tomcat 会收到请求. 如果发现内存溢出, 那么就可能会定位到是 tomcat 配置的问题; 如果请求返回 404, 也可能是 nginx 配置不当. 当然, 这个时候可能会遇到一些环境问题, 比如测试环境没有的问题, 到线上就有了, 很可能是环境原因, 比如 jdk 版本不同, tomcat 版本不同, jar 包版本不同等等.
最后一层是数据库. 代码没有问题, 不代表软件没有问题. 数据库层面也可能会有各种各样的问题, 比如字段的约束问题等等. 假如一个文本框的前端校验和接口校验的文本长度最大是 50, 但数据表字段设定的是 varchar(30), 那么在存数据的时候肯定会报错. 再比如之前发现一个数据库的问题, 测试环境没有, 到线上却有了, 那么也可以看下是不是数据库版本不同导致的.
上面我们说的是问题定位的一个大致思路. 每一个环节都有可能出现 bug, 既可能是 response 的问题, 也可能是前端回调处理的问题. 有的问题可能会直接暴漏在用户面前, 有些则可能需要我们去分析日志.
当然, 很多时候我们不需要这样一层一层去定位, 经验丰富的开发或者测试根据现象可能马上能定位到究竟哪里出了问题.
来源: http://www.bubuko.com/infodetail-3501629.html