定位问题没有银弹!
定位问题没有银弹!
定位问题没有银弹!
老张结合自己的工作经验,谈谈问题为什么会产生,已经定位后端问题的一些经验总结。
01、Bug是如何产生的?
计算机是精确的,而人是非理性的。这是Bug之所以会产生,且一直烧之不尽的本质原因。如果将编程比喻成施咒,一个字符、一个停顿,没有与正确的形式一致,咒语就不会生效。
另外还有一个次要原因:开发目标、所需资源往往都是由他人提供的,程序员很少能够自己控制工作环境和工作目标。
综上,程序员能做的只是不断逼近完美,但是并没有办法将Bug从软件中彻底清除。
02、后端开发的现状
目前,搭建若干套环境是目前技术公司都会采用的方案。这里抽象为开发环境、测试环境、线上环境,三者之间共用一套程序,但是数据是隔离的。
开发环境由开发人员维护,主要用于验证方案,调试程序,变更频繁但是数据单一。由于开发能够直接介入,这个阶段出现的问题往往都能够被很快的解决。开发自测通过后,程序会被发布到测试环境。
测试环境相较于开发环境更加稳定,数据也更接近线上环境。开发收到的问题反馈大量的集中在这一阶段,而且由于不能直接介入,定位与解决问题的难度开始提升。测试人员测试通过后,程序正式向用户发布。
线上环境是直接面向用户的,流量大且请求多样。请求多样意味着正式环境能够暴露前两个阶段未能发现的问题,流量大意味着出现问题往往就会造成重大影响。与测试环境一样不允许开发直接介入,但对于定位问题的速度要求更高。
03、一个请求在哪会出问题?
单点服务模型的优点是运行稳定。但是运行稳定并不意味着不会出错,如果某次请求产生了意料之外的结果,很大的可能是发生在Service内部或者客户端与服务器交互,极少数情况下发生于Nginx、DB以及其他系统之间的交互。
单点服务模型的缺点也很明显,就是容易遇到性能瓶颈。优化性能的措施有很多,比如DB的读写分离、引入缓存、水平扩展Service、多台服务器DNS轮询等等。但是每引入一项措施,都会损失一部分系统稳定性。优化后的系统相较于单点模型,组件内部及组件之间的出现问题的可能性均在增加。
04、如何快速定位问题?
定位问题也遵循上面的流程。知道了为什么会出现问题,以及在哪会经常出现问题之后,遇到问题,就可以根据问题表现做到有的放矢。
一、客户端到服务器之间的问题
客户端到服务器之间问题因为牵扯到请求消息内容、网络环境等因素,往往需要引入工具来帮助定位。
-
如果怀疑网络不通,ping/telnet命令能够很快速的判断客户端与服务器之间的网络是否正常。
-
浏览器的开发者工具(F12)是快速定位网页问题的利器。
-
APP与服务器之间的交互往往都是API,Postman除了支持主流的Restful,最近的版本也引入了对Graph的支持。
-
Pc所有的网络流量在Wireshark面前都无所遁形。
-
手机请求不能像浏览器一样容易抓包,HTTP抓包利器Fiddler的代理模式值得一试。
二、
服务器内部问题不同客户端的地方在于不可见,无法像客户端一样通过引入工具可视化的定位问题。此时能够帮助快速定位问题的一是Shell命令,二是运行日志。
Shell命令数量大且不易掌握,但却是一个后端绕不过去的基础知识。这里推荐两本书:
-
《Linux系统命令及Shell脚本实践指南》可以帮助理解Linux的模块设计,以及掌握Shell。
-
《鸟哥的Linux私房菜:服务器架设篇》各种实例可以快速掌握相关命令。
选择print而不是打印日志是新手常见的一个问题。
-
什么时候打日志?
-
打印什么级别的日志?
-
什么样的日志格式最有帮助?
-
日志文件的存放期限?
等等一系列的问题往往都是血与泪的教训换来了。
05、总结
定位问题不要只盯着问题,要多思考问题是怎么来的,问题之间有没有共性,如何才能避免类似问题的发生。
定位问题没有银弹,要做到快速定位只能是唯手熟尔!
最后,老张考虑后面再写几篇文章介绍一些工具的使用技巧,已经分享几个自认为有意思的Bug。