根据bug的大小,如果影响业务逻辑及用户提醒及时处理,如果只是一些状态.文案等等对业务无重大影响可以跟版本迭代走 很严重的bug必然要回滚,想都不要想赶紧去着手安排做. 检查回滚版本是否会丢失数据,如果危害小可以让用户自己决定是否忽略(推送告知用户会丢失哪些数据一般说「部分数据」),如果危害大,替问题用户保存好数据并告知用户不要轻易回滚. 配合开发及测试人员,快速定位bug,并且锁定影响范围. 做好备份,及时发出上线公告,产生bug的功能暂且不上线,其他功能继续上线. 上线成功后,做一个上线总结

线上BUG说处理方法:1.关于线上BUG问题,目前公司有一整套线上故障流程规范,包括故障定义.定级.处理流程.故障处理超时升级机制.故障处理小组.故障处罚(与故障存在时长有关)等:2.最主要的是,线上故障是研发和测试团队的KPI,KPI计算是分开的,线上只要出现BUG,研发必须承担责任:对于测试来说,是复盘的时候确认是不是漏测,只有漏测才会计算测试责任:3.最重要的是,公司从上下都重视这套故障流程规范,所以应该先建立规范:并让大家都认可,这样研发在开发的时候才会尽心尽力,测试也有更多时间做测试的

这里系统专门指的是那种用户量大的系统,比如有几百万或者上千万的注册会员.因为小系统因为用户量少,不存在这种思考,考虑有时候是多余的.另外还有内部系统,给自己公司内部人员使用的,即便是出现了问题,也不会造成很大的问题,内部协调一下即可. 而针对客户的系统,公司的收入和价值来源于给客户提供稳定的服务.这是关系到公司命脉的.如果系统不稳定,在客户心中造成的印象就会不好. 快速修复与稳定测试之间的权衡 如果线上系统出现了bug,用户反馈问题.作为开发人员,肯定要修复bug.是马修复代码后上传到生产环境,

下游发现接口可用率非100%,马上线上查看,发现数据在有些情况下通用补数的数据是空, 有20%的用户是没有相应偏好等的数据的,需要通用补数来补数,结果通用补数没有数据. 通用补数数据的检查报警时必须要存在的,否则通用补数导致线上程序bug,总结一下,避免 后续再犯.

摘要: Source Map还是很神奇的. 原文:线上出bug了?别怕,这么定位! 公众号:前端小苑 Fundebug经授权转载并修改,版权归原作者所有. 工作中,生产环境代码是编译后代码,搜集到报错信息的行和列无法在源码中对应,很多时候只能靠"经验"去猜,本文针对这种情况,开发了一个npm命令行小工具,帮助快速定位报错的源码位置,提升效率. 由于现在构建工具盛行,前端部署的代码都是经过编译,压缩后的,于是乎,SoueceMap就扮演了一个十分重要的角色,用来作为源代码和编译代码之间的

在以往的工作中,线上一有bug,就需要把文件弄到本地来改,但经常会碰见本地环境又和线上不一样,导致调试困难,闭着眼睛改好之后传到线上去看对不对,不对的话又要改,循环往复,要多麻烦就有多麻烦啊. 今天给大家介绍一款前端神器,Fiddler ,它有个功能就是把线上文件映射到本地,通过拦截的方式,你在本地修改的内容实时的反映到线上,线上的环境,本地的文件,这非常方便我们调试,而且也不会给线上带来严重的错误,因为这些操作只对你本机有效哦. 点击下面链接: http://blog.mingsixue.co

前言 前几天跟读者聊天,他说被产品经理给怼了.原因是线上出 Bug 了,最后是客户反馈才知道的. 我就问他:你们是不是没做监控? 读者:我们是刚成立的创业团队,目前最重要的就是堆功能,很多基础设施都没时间做. 正所谓有多大的碗吃多少的饭,不要盲目追求规模大,很牛的那种方案,合适的就可以.监控亦是如此,小方案只要够用,能解决问题,也是非常不错的选择. 下面给大家介绍一些常用的异常监控方式: 最小成本化 如果是刚成立的创业团队,可以用最小的实现成本来对系统的异常进行实时监控.所谓最小的实现成本,就是

线上的应用只要用心点点都能发现些bug,连微信,QQ也不列外.但是bug中最严重的算是闪退了,这导致了用户直接不能使用我们的app. 我们公司是特别注重用户反馈和体验的,我们会定期打电话咨询用户的使用情况.我们也有自己的天使用户群,这些用户会跟我们及时的反馈应用的使用情况,bug情况,还有他们的需求. 用户不是技术人员他无法跟你清楚的描述怎么产生闪退的,于是我们需要一个bug统计的功能,我们公司采用友盟统计实现bug的记录.我们在iOS应用中植入友盟统计的功能,我也经常在查看友盟的错误统计和错误

如果你有以下痛点,请你查看本文章: 1.我改的代码为什么没有执行到?难道是我没 commit?分支搞错了? 2.遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 3.线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现! 4.是否有一个全局视角来查看系统的运行状况? 5.有什么办法可以监控到JVM的实时运行状态? 6.怎么快速定位应用的热点,生成火焰图? Arthas-解决以上所有问题 一.快速启动,(我的第一给demo) 1.下载git代码,本地启动app

在Windows上工作时未出现过该问题,于是通过命令: git diff 查看差异,得到结果: diff --git a/start_crons.sh b/start_crons.sh old mode new mode 这是由Linux严格的文件系统权限导致. 通过命令关闭filemode解决: git config core.filemode false

针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现.重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的 关于Hot Fix技术 Hot Fix技术,简单来说就是针对线上已发布app出现了bug,在不推送新版本的情况下通过发布修复补丁进行修复.通常是刚上线的app,需要快速线上修复bug,类似的技术就叫做热修复或热补丁. 热修复技术能带来什么 让app具有了上线后被修复的可能性,增加事故风险可控性: 避免为修复bug而快速增发新版本,让

前言 在部署线上项目时,相信大家都会遇到一个问题,线上的 Bug 但是在本地不会复现,多么无奈. 此时最常用的就是取到前端传递的数据用接口测试工具测试,比如 POSTMAN,复杂不,难受不? 今天陈某教你一招,让你轻松调试线上的 Bug.文章目录如下: 什么是 JPDA? JPDA(Java Platform Debugger Architecture),即 Java 平台调试体系,具体结构图如下图所示. 其中实现调试功能的主要协议是JDWP协议,在 Java SE 5 以前版本,JVM 端的实

前言 作为后端开发工程师,当收到线上服务器CPU负载过高告警时,你会这么做?重启服务,忽略告警?不过在我看来一个合格的工程师是一定要定位到具体问题所在的,从而 fix 它.下面记录一下线上服务器 CPU 负载过高排查过程,把排查流程理清楚,以后遇到问题将会迅速定位到问题所在,快速解决. 什么样的场景会导致线上CPU负载过高? 代码层面常见的场景有: 程序陷入死循环,不停地消耗CPU 线程死锁,线程相互等待,导致假死状态,不停地消耗CPU 程序死循环场景 这里使用 JAVA 简单模拟程序死循环带来

前言 大多数情况下,我们会在打印日志时定义日志的LOGGER级别,用来控制输出的信息范围. 一方面,过多的输出会影响查看日志的效率,另一方面,过少的日志让问题定位变得困难. 但当线上出现问题时,线上容器通常定义在info级别,发生一些疑难问题时,光靠info级别的日志很难定位问题. 一个典型的场景:在一些需要打印MySQL语句的场景,如果你正在使用MyBatis框架,由于MyBaits中SQL语句是DEBUG级别的信息,通常在线上容器就没法看到. 一个丑陋的解决办法就是在沙箱/预发环境,将log

最近在做产品需求的时候上线了一个新的产品需求,给用户多了一种新的排序排序规则,更加方便用户找到自己想要的东西.新版本发布后,QA 给我发了一个 线上崩溃 bug 链接,具体内容如下: 看到上面的链接,我有点懵逼了,就这排序还能给我搞出 bug 来?看到抛出的异常信息,也没有见过,于是直接百度搜索了. 一百度,发现很多人遇到这个问题,下面简单说下出现这个问题的原因: 在 JDK7 版本以上,Comparator 要满足自反性,传递性,对称性,不然 Arrays.sort,Collections.s

一.Fiddler在线调试功能和表白神器介绍 ​ 在以往的工作中,线上有bug,就需要把文件弄到本地来改,但经常会碰见本地环境又和线上不一样,导致调试困难,闭着眼睛改好之后传到线上去看对不对,不对的话又要改,循环往复,要多麻烦就有多麻烦啊. 今天给大家介绍一款前端神器,Fiddler ,它有个功能就是把线上文件映射到本地,通过拦截的方式,你在本地修改的内容实时的反映到线上,线上的环境,本地的文件,这非常方便我们调试,而且也不会给线上带来严重的错误,因为这些操作只对你本机有效果. 它还是对女神表白

线上centos6出现软死锁 kernel:BUG: soft lockup 今天线上一台centos6机器用xshell一直连接不上,然后在xshell上显示 Message from syslogd@GZxxx at Mar 29 14:13:14 ...kernel:BUG: soft lockup - CPU#1 stuck for 68s! [events/1:36] 过了10分钟,终于可以连上了,看一下开机日志 dmesg |grep stuckBUG: soft lockup -

昨天下午大神把组内几十号人召集在一起开Online bug分析大会,主要是针对近期线上事故从事故原因和解决方案两个维度来分析. 对金融软件来说,每一次的线上事故都有可能给公司带来重大的损失,少扣了用户的钱,为公司带来资金方面的亏损:多扣了用户的钱,则为带来不必要的合约或法律纠纷,故测试金融软件不比其他行业的软件,后者线上bug大多不会直接引起资金方面损失,最多就是用户体验不好,功能没有实现,导致用户量的流失. 对金融软件来说没有小bug,一旦出现bug那就是重大的bug,必须引起高度重视. 俗话

在测试账户系统过程中遇到了线上大面积用户登录态失效的严重问题,事后对于其原因及测试盲点做了一些总结记录以便以后查阅,总结分为以下7点,其中原理性的解释有些摘自网络. 1.账户系统token失效问题复盘2.Redis 经典流程3.Redis分片部署方式4.Redis扩容导致缓存数据失效5.Redis Sharding一致性hash算法6.缓存失效,缓存击穿,缓存穿透7.Redis缓存测试总结 账户系统token失效问题复盘现象:redis扩容后线上大量用户登录态失效,需要重新登录.由于登录态可以持

缘由 本人从事游戏开发很多年一直都是游戏服务器端开发. 因为个人原因吧,一直在小型公司,或者叫创业型团队工作吧.这样的环境下不得不逼迫我需要什么都会,什么做. 但是自我感觉好像什么都不精通..... 好了好像偏题了! 回归正题 现在公司是做手游开发,java服务器 + U3D做客户端的mmo手游,仿魔兽世界! 做软件的都知道一个蛋疼的事情,那就是线上Bug.但是做服务的人更清楚另一个蛋疼的事情,就是在线更新,不停服更新. 知道的人,想想都蛋疼,当然不知道的,那就只能自己想象了. 线上经常出问题大

简述C#中IO的应用   在．NET Framework 中． System.IO 命名空间主要包含基于文件(和基于内存)的输入输出(I/O)服务的相关基础类库．和其他命名空间一样． System.IO 定义了一系列类.接口.枚举.结构和委托.它们大多数包含在 mscorlib.dll! 另外有一部分部分 System.IO 命名空间的成员则包含在systcm.dll程序集中.System.IO命名空间的多数类型主要用于编程操作物理目录和文件,而另一些类型则提供了从字符串缓冲区和内存区域中读写数