对于服务端bug处理的一些建议

概述

  • 方法

接到一个bug单,应该肿么入手?

  • 工具

定位bug我们常用的工具和命令。

  • 减少bug的建议

Bug难也避免,但是有办法减少bug的产生。

一、方法

1.了解bug的相关信息

定位bug前,首先要搜集有关bug的相关信息,不要盲目下手

(1).业务逻辑

清楚bug所在业务的逻辑,了解正常的流程应该是什么,业务的入口在哪里,重现的步骤

(2).影响人群

学生/机构

(3).影响范围

*.影响哪些端的用户:全端/pc-web/老师客户端/pc学生客户端/h5/安卓/ios

*.所有用户/个别特殊逻辑的用户

(4).相关人员

清楚bug相关的人员,反馈的同事/测试/产品/客户端/移动端/前端/CGI/后台/……

2.注意事项

严重的bug立即上升,让老司机开车带你,尽快减少影响范围,可能的情况下留住现场。

ps:要充分信任自己的leader和导师,如果是自己失误导致的严重问题,不要想着自己掩盖,偷偷去改,要立即反馈给leader,他会想怎么帮助你解决,怎么保护你。

关键时刻扛起责任,如果发现致命bug,第一时间打电话给老司机,不知如何处理的情况下重启服务,可能会解决大部分问题。

可能的情况下保留一个现场,比如10台机器上的服务都挂了,先重启9个机器的服务,另一个机器踢掉L5保留下来。

3.BUG处理的标准流程

(1).提单

防止理解失误/数据操作错误,bug交流的流程中极其有可能数据失真,特别是中途转给你的bug。

血泪教训:曾处理一个机构修改银行帐号的bug,中途被拉入rtx群,A机构银行帐号修改失败,但是机构id搞错了,导致把B机构的银行帐号改了,影响了结算,还好即时发现。

(2).测试复现

测试复现会帮助开发过滤调用户理解错误,操作错误引发的问题,排除无效bug。

复杂的复现逻辑测试人员构造更熟练。

(3).确认哪个过程产生的Bug

熟练的话自己定位bug出现在那个流程,不熟悉的话跟进每个流程的负责人定位问题的产生在哪里。

(4).修改bug

确认bug产生的原因,修改方案并且和导师过下。

(5).测试验证

确认bugfix并且没有引入新的bug,给出测试建议

4.问题跟进

有的bug涉及流程较长,需要跟进每个流程定位,需要技巧

首先要以项目成功为目的,善意地寻求解决问题的办法,避免陷入互相推脱和恶意PK的境。

(1).找到第一负责人

跟进到每个流程,找到该流程第一负责人,方便推动

(2).采用合理的沟通方式

企业微信/QQ/微信、电话、邮件、face2face

(3).拉群跟进

*.方便知会相关干系人。

*.同样问题可以重新在这个群中反馈,积累大家合作的顺畅度和熟悉度。

*.处理流程会沉淀在聊天记录中,对方业务交接换新人的时候,可以翻出聊天记录指导对方。

ps:处理常见问题的群要防止别人误操作踢人或者解散群,收回他人踢人和解散群的权限。

(4).适时上升

*.对方难以推动的时候,拉入自己leader和对方leader,让老司机帮你push。

*.跨部门合作的时候。

*.涉及关键服务的时候。

(5).不要跟丢问题

建立闹钟或者备忘录,防止跟丢问题。

不是自己的问题要即时转单(tapd单),不要让流程卡住。

二、工具

1.前端到cgi(cgi这里指接入层/胶合层)

(1).Chrome开发者工具

*.抓包 可以抓取pc-web端和H5端的各种http请求,并且可以进行筛选

*.资源查看 查看cookie和静态资源

*.审查工具 可以审查页面上静态资源,确认是cgi返回值的问题或者是前端问题,经常用来定位图片加载不出来的问题

*.控制台工具 发请求,处理乱码文本(decodeURI,decodeURIComponent)等

(2).Fiddler/postman

发http请求,调试cgi

2.Cgi-后台

Cgi-后台问题的定位

(1).后台client工具

可以构造请求向后台发包,确认后台是否正常。

(2).tcpdump+wireshark(前端-cgi,cgi-后台问题定位都适用)

常用在分析

*.解包错误

*.请求来源和请求包无法确定

3.日志分析

日志分析是bug定位的首要必备技能

(1).强大的grep命令

常用选项

-n :显示行号

-A 行数 :查看关键字之后(after)指定行数的文本

-B 行数 :查看关键字之前(before)指定行数的文本

-C 行数 :查看关键字所在行之前和之后指定行数的文本 -v :排除关键字所在的行

--color 对grep的文本着色

注意对于特殊字符进行转义 \

(2).大日志的查看技巧

*.cat -n edu_class_offline.INFO | grep "16:47:0" | head -1

找出16:47的第一行日志

*.sed -n ‘7494165,7888317p’ edu_class_offline.INFO > 070616.info

截断指定行之间的日志

*.tail –n 行数 文件

查看该日志文件最后n行

*.less/more

(3).调试必备

tail –f 将日志刷新到屏幕

(4).全链路日志体系查看

对于多级部署,调用链路长的业务,我们会建设全链路日志体系,可以生成traceid\spanid等方便快速定位异常节点(基于elk,zipkin,tick的全链路日志系统,后续会有介绍)

4.后台-系统状况

(1).强大的top命令

*快捷键:

1:查看各个cpu状况

M:按照内存状况排序

P:按照cpu使用率排序

cpu列详细介绍(这一列许多新同学不理解,查看英文解释,更加容易理解和记忆)

us: user cpu time (or) % CPU time spent in user space(用户态使用的cpu时间比)

sy: system cpu time (or) % CPU time spent in kernel space(系统态使用的cpu时间比)

ni: user nice cpu time (or) % CPU time spent on low priority processes(用做nice加权的进程分配的用户态cpu时间比)

id: idle cpu time (or) % CPU time spent idle(空闲的cpu时间比)

wa: io wait cpu time (or) % CPU time spent in wait (on disk)(cpu等待磁盘写入完成时间)

hi: hardware irq (or) % CPU time spent servicing/handling hardware interrupts(硬中断消耗时间)

si: software irq (Interrupt Request)(or) % CPU time spent servicing/handling software interrupts(软中断消耗时间)

st: steal time - - % CPU time in involuntary wait by virtual cpu while hypervisor is servicing another processor (or) % CPU time stolen from a virtual machine(虚拟机偷取时间,有虚拟cpu的情况)

(2).free命令

经常有疑问的点 buffer和cache的区别

*.A buffer is something that has yet to be "written" to disk.

*.A cache is something that has been "read" from the disk and stored for later use.

-buffers/cache

used:一个应用程序认为系统被用掉多少内存;

free:一个应用程序认为系统还有多少内存;

FO[3][2] = FO[2][2] - FO[2][5] - FO[2][6]

系统实际被用掉的内存=总的被使用的-buffers-cached

FO[3][3] = FO[2][3] + FO[2][5] + FO[2][6]

还有多少内存可用=空闲的内存+buffers+cached

(3).统计工具

•vmstat 检测cpu 内存问题

•iostat 检测是否是磁盘I/O问题

•netstat检测是否是网络带宽问题

(4).lsof

列出某个进程打开的所有文件信息

http://km.oa.com/group/24327/articles/show/242207 定位文件描述符泄漏流程

5.后台-进程维度

(1).pmap

提供了进程的内存映射,pmap命令用于显示一个或多个进程的内存状态。其报告进程的地址空间和内存状态信息

(2).valgrind

用于内存调试、内存泄漏检测以及性能分析的软件开发工具

(3).time

显示程序执行时间、其中用户态时间、其中内核态时间 time只跟踪父进程,所以不能fork

(4).perf

kernel自带的系统性能优化工具,用于查看热点函数。

(5).strace

显示程序调用的系统调用

用途:Debug、性能分析、学习现有程序

重要参数:-c计算各个系统调用累计占用的时间 -T –tt显示单个系统调用的开始时间、执行时间

(6).ltrace

显示程序调用的动态库函数

用途:Debug、性能分析、学习现有程序

重要参数:-c计算各个函数累计占用的时间 -T –tt显示单个函数的开始时间、执行时间

(7).gprof

显示各个函数的执行时间

不能strip •必须通过正常途径退出(exit()、main返回),不能kill -9

只管了用户态时间消耗,没有管内核态消耗 •可对c库函数进行性能分析,libc_p.a (gcc –lc_p)

原理:gprof 在编译或链接源程序的时候在编译器的命令行参数中加入“-pg”选项,编译时编译器会自动在目标代码中插入用于性能测试的代码片断,这些代码在程序在运行时采集并记录函数的调用关系和调用次数,以及采集并记录函数自身执行时间和子函数的调用时间,程序运行结束后,会在程序退出的路径下生成一个gmon.out文件。这个文件就是记录并保存下来的监控数据。可以通过命令行方式的gprof或图形化的Kprof来解读这些数据并对程序的性能进行分析。另外,如果想查看库函数的profiling,需要在编译是再加入“-lc_p”编译参数代替“-lc”编译参数,这样程序会链接libc_p.a库 ,才可以产生库函数的profiling信息。如果想执行一行一行的profiling,还需要加入“-g”编译参数。 例如如下命令行:gcc -Wall -g -pg -lc_p example.c -o example strip经常用来去除目标文件中的一些符号表、调试符号表信息,以减小程序的大小。

三、减少写bug的建议

1.理清需求

需求变更是大部分bug产生的原因

*.理清产品对于需求的描述,防止误解

*.技术层面帮助产品完善需求,尽可能减少会给技术方案留坑的产品逻辑

*.了解产品对需求未来的规划,保证技术方法的可扩展性

2.代码规范

*.编码的规范性(优先非条件 参数检测 不可能分支assert)

*.接口设计

*.合理的抽象,尽可能的复用

3.日志和监控

*.合理的日志打印(关键路径、异常逻辑)

*.通过监控,即时发现bug

4.代码评审+codereview

5.自测(功能测试,压力测试,必要的时候需要单元测试)

6.积极和测试同学沟通,给予测试同学测试建议

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

大型网站的灵魂——性能

Via: http://blog.jobbole.com/84433/ 前言 在前一篇随笔《大型网站系统架构的演化》中,介绍了大型网站的演化过程,期间穿插了一...

3296
来自专栏java一日一条

测试代码时你会犯的 11 个错误

我遇到的大多数开发人员都不怎么热衷于测试。有些会去做测试,但大多数都不测试,不愿意测试,或者勉而为之。我喜欢测试,并且比起编写新的代码,愉快地花更多的时间在测试...

672
来自专栏顾宇的研习笔记

AWS 上的生产环境架构优化案例

在AWS 上的生产环境性能分析案例一文中,记录了我对客户应用生产环境的一次性能分析。接下来,我们要根据所发现的性能问题进行架构优化,以提升可用性和性能。同时,这...

1471
来自专栏jerryteng的专栏

如何利用最低配的腾讯云快速搭建高并发在线服务

这里是作为开发用,我们就选择一个普通的服务器,我也是很不好意思的申请了相关的学生机,那我们就用学生机来搭建一个高并发的在线服务。这个机器配置很低,我还进行了降级...

93310
来自专栏owent

libatbus基本功能及单元测试终于写完啦

经过茫茫长时间的编写+过年在家无聊补充和修正单元测试,再加上这两天的整理,终于把以前的这个关于服务器通信中间件的基本功能和相应的单元测试完成啦。还是可以热烈庆祝...

962
来自专栏服务端技术杂谈

动手撸一个规则引擎

最开始听说过规则引擎可能是一个类似于OA的系统中,通过规则配置,让一个审批流程得到配置化和规则化。

1724
来自专栏后台全栈之路

基于汇编的 C/C++ 协程 - 背景知识

近几年来,协程在 C/C++ 服务器中的解决方案开始涌现。本文主要阐述以汇编实现上下文切换的协程方案,并且说明其在异步开发模式中的应用。

3144
来自专栏魏琼东

基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET平台开发指南 - 实现业务

业务分层         依据行业经验来看,分层是解决复杂问题的简单方法,通过分层,可以把一个复杂问题分解为不同层次应用的小问题,解决各层小问题的难度小于总的问...

19510
来自专栏FreeBuf

利用HTTP参数污染方式绕过谷歌reCAPTCHA验证机制

今年初,我上报了一个谷歌reCAPTCHA验证码绕过漏洞,该漏洞在于能用一种HTTP参数污染的不安全方式,让Web页面上的reCAPTCHA构造一个针对 /re...

2993
来自专栏java思维导图

图说分布式架构的演进

初始阶段的小型系统、应用程序、数据库、文件等所有的资源都在一台服务器上。通俗称为LAMP。

1101

扫码关注云+社区

领取腾讯云代金券