反思了下,解决问题无外乎3w1h when where who how 就是查询出来的事情多了,现在不知道哪个地方出问题,应该根据日志一步一步梳理,查看每一步的输出结果是否与预期一致 顺藤摸瓜 觉得不清楚的地方,可以新增打印,或通过其它方法获取这些不可知的信息. 已经确认没有问题的代码,不能出异常情况时,就开始漫无目的的怀疑,张驰有度... 严格的讲这个Bug还没有彻底解决,因为没有找到真正的原因 重启下服务就好了!!!!!!!!!!!!!!!! 主要想梳理下操作流程: 当时的反应: bug出现

8.4 异常观测值 8.4.1 离群点 car包也提供了一种离群点的统计检验方法.outlierTest()函数可以求得最大标准化残差绝对值Bonferroni调整后的p值: > library(car) > outlierTest(fit) rstudent unadjusted p-value Bonferonni p Nevada 3.542929 0.00095088 0.047544 可以看到Nevada被判定为离群点(p=0.048).注意,该函数只是根据单个最大(或正或负)残差值

问题:QA突然发个截图说一个Dialog上展示的东西变形了 分析:不理解,什么也没做,怎么会变形,刚刚我用的时候还正常.看看代码,的确什么也没更改:在本地测一下,也没有问题:baidu,bing,stackoverflow下,没找到什么线索 突然看到一个ComboBox下面有一个item的值比较长, 布局使用的是GridBagLayout,也就是相对布局,如果设置Size是固定的,如果有一个控件变大,则整体的布局变形了 因此这个Combobox item的值比较长解决了,这个问题就解决了. 解决

前言 最近接收了一个老项目,突然甲方 QA 报了一个 bug,连续请求 60 次,成功 8 次,后面的 52 次全部失败,而且成功的 case 返回时间普遍较长.看了日志,并非业务上的异常.这让刚毕业没什么经验的我,顿时陷入了沉思.但回过神来考虑了一下,大胆才猜测,可能是网络问题或者是并发请求上的问题. 但其实业务异常相对容易排查,而网络或者并发的问题会相对难一些,刚好自己对于服务器服务器请求处理的流程也不太清楚,所以就花了时间看了下,最后基本断定是接口是实现方式出现了问题,重新改写成异步接口后

Jmeter用于tomcat性能测试,因为项目部署在tomcat,正常情况下,一个tomcat可以承受500个并发,通过修改配置,及其相关的tomcat优化,可以承受到1000个并发. 如何测试tomcat优化前和优化后的结果? 通过Jmeter测试,就能达到对应的效果 Jmeter测试tomcat比较简单 1.建立对应的线程组 2.建立Http请求 需要填写的一个是协议名称,一个是IP地址或域名,一个是端口号,还有一个是路径 这个路径默认不填也行,如果具体到post或get请求及其携带参数,就

一.对需求评审阶段,对业务需求细节理解不明确,未深入挖掘隐含拓展需求 改进措施 需求评审前,我们应该先仔细阅读prd及交互文档,先形成自己对产品的思考,通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找出产品设计缺陷点: 需求评审会议中,带着列出的疑问点向产品.开发沟通自己对产品的疑惑和质疑点,多提几个为什么?如何实现?数据获取来源?超出预期的数据怎么处理?缓存处理机制如何?数据保存何处?逻辑由前端处理还是后端服务?后端服务逻辑是否跟第三方关联? 需求评审完成后,按照一定的功能,将需求

http://blog.csdn.net/ronintao/article/details/51649664 参考 1.Common Techniques to Improve Shadow Depth Maps 2.Tutorial 16 : Shadow mapping 3.Shadow Mapping 4.Shadow Mapping Algorithms 5.Shadow Map阴影贴图技术之探 6.Cascaded Shadow Maps 写在前面 之前已经很久没有再更新博客,上一篇已

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

关于故障的事后复盘,英文名 Case Study是非常有必要做的,当然是根据故障的级别,不可能做到每个故障都Case Study,除非人员和时间充足: 文档能力也是能力的一种,一般工程师的文档能力比较薄弱或者一般 ,但是一般各种类型的文档其实都有模板,根据模板填充内容也能事半功倍. 故障要有记录, 每个公司应当都有wiki,这些复盘应当记录下来,能学习到很多.Case Study会占用大量的时间, 但是中级以及重大故障还是有必要的. 下面介绍的就是复盘的整体套路: 故障描述 xxx业务状态码报警

美图崇尚的故障文化是 "拥抱故障,卓越运维",倡导的基准是 No-Blame, 即「不指责,重改进」.今年 9 月 TakinTalks 社区曾经分享过美图的三段式故障治理方法(美图 SRE:一次线上大事故,我悟出了故障治理的 3 步 9 招),这次重点讲讲故障治理中的最后一个重要环节 -- 故障后的复盘,在这个过程里可以总结吸取经验教训并改进,这样才能让整个系统的稳定性得到实质性提升. 作者介绍:美图 SRE 负责人 - 石鹏 TakinTalks 社区专家团特聘讲师.2016 年加

原文:[原创]构建高性能ASP.NET站点 第六章-性能瓶颈诊断与初步调优(下前篇)-简单的优化措施 构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施 前言:本篇给出一些在部署ASP.NET站点时采用的简单的优化措施.同时很也非常的感谢朋友对昨天发的文章的支持,本篇的内容不多,也比较的简单! 本篇议题如下: 识别和分析服务端的性能瓶颈(上) 内存(前篇) 缓存(前篇) CPU(前篇) 处理请求线程(前篇) 提高性能的一些简单改进措施(下)         

5月20日本,Qt 官方博客宣布 Qt 5.3.0 公布! 这个版本号聚焦在性能.稳定性和可用性的提升上,与 5.1 / 5.2 相比有非常大提升. 5.3.0 的主要变化: 稳定能.可用性大大提升 Qt for Windows Runtime Beta Official support for QNX 6.6 and QNX 6.5 SP1 引入的新特性 QQuickWidget,混合使用 Qt Widgets 和 Qt Quick 变得更加方便 Compiled Qt Quick Purch

导读 2014 年开源加密库 OpenSSL 项目爆出的高危漏洞 Heartblood 让世人意识到一些鲜为人知的开源项目对整个互联网和其它基础设施的完整性和可靠性至关重要,随后 Linux 基金会发起了 Core Infrastructure Initiative(CII)倡议. 2014 年开源加密库 OpenSSL 项目爆出的高危漏洞 Heartblood 让世人意识到一些鲜为人知的开源项目对整个互联网和其它基础设施的完整性和可靠性至关重要,随后 Linux 基金会发起了 Core Inf

哈佛商学院最受欢迎的领导课 英文版出版于2011年,还不算旧.中信2013年出过一版,这版估计是英文书版权过期后重新购买了再出版. 全书以写给CEO的口吻讲了许多管理常识,包含一些CEO容易犯的问题和一些改进措施,比如CEO最后一个听到公司内的建设性意见,比如设置一个特别小组来重新考虑公司的愿景. 作者非常重视以下方面的管理工作:认真考虑愿景:做好时间管理和任务清单:及时给予下属反馈而不是等到年终:要有接班人计划:及时调整战略:给员工做好的表率. 读后感觉作者确实有不少管理教练方面的经验. 作者

大家接触的第一个聚类方法,十有八九都是K-means聚类啦.该算法十分容易理解,也很容易实现.其实几乎所有的机器学习和数据挖掘算法都有其优点和缺点.那么K-means的缺点是什么呢? 总结为下: (1)对于离群点和孤立点敏感: (2)k值选择; (3)初始聚类中心的选择: (4)只能发现球状簇. 对于这4点呢的原因,读者可以自行思考下,不难理解.针对上述四个缺点,依次介绍改进措施. 改进1 首先针对(1),对于离群点和孤立点敏感,如何解决?笔者在前面的一篇博客中,提到过离群点检测的LOF算法,通

解Bug之路-串包Bug 笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug.现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后的工作中能够少踩点坑. 串包Bug现场 前置故障Redis超时 由于某个系统大量的hget.hset操作将Redis拖垮,通过监控发现Redis的CPU和IO有大量的尖刺,CPU示意图下图所示: CPU达到了100%,导致很多Redis请求处理不及时,其它业务系统都频繁爆出readTimeOut.此时,紧急将这个

2016年11月30日13:22:26[转] CTO.技术总监.首席架构师的区别 提升自已的能力,比如专业技术,行业发展趋势,技术发展趋势,协调能力,组织能力,管理能力等[技术总监] 需要从技术总监和研发Leader身上剥离职责.让技术总监和研发Leader偏项目管理(管理族),把各个模块之间的架构设计工作,独立出一个岗位,就是架构师,来负责.[首席架构师] 真正的CTO,是软件产品和技术是统一管理的.商业.产品.技术.管理.团队相平衡的综合统管[首席技术官CTO] 一.高级程序员 如果你是一个

文章大纲 一.架构师定义二.架构师分类与具备能力三.研发人员发展的技术路线四.架构师知识体系五.参考文章   一.架构师定义   什么是架构师,这个聊架构话题时永恒的问题.每个公司对架构师的定位也有所不同,因为不同公司所处的阶段,业务模式,应用场景也都不一样.对架构的要求也不一样.  在初创公司的野蛮生长阶段:业务场景和需求边界很难把握,有时候根本不需要架构师,产品需要快速迭代和变现,需求频繁更新,这个时候需要的是快速实现.当然如果公司成长以后,这个阶段就是欠下很多技术债,埋下很多坑,如果人员流

故障review的一些总结 故障review的目的 归纳出现故障产生的原因 检查故障的产生是否具有普遍性,并尽可能的保证同类问题不在出现, 回顾故障的处理流程,并检查处理过程中所存在的问题.并确定此类问题的处理方法论.使得即便以后出现了同类的问题,也有明确的方法论来指导 标明后续改进措施及落实时间点 经验总结和分享 故障的级别定义 不同公司对于故障的级别有不同的定义,一般会有P1,P2,P3这几类故障,故障的严重级别依次降低.一个可能的定义如下: P1 公司主站提供的服务出现异常,广告展示出现问

昨天上课的时候,我们学习了项目总结这一部分的内容,并根据老师提供的项目Postmortem模板对我们的项目进行了总结. 项目Postmortem模板主要分为设想和目标.计划.资源.变更管理.设计和实现.测试和发布六个方面.根据这个模板,我们对我们的项目进行了总结,会议的主要流程分为三个方面:第一,按照模板提供的六个方面探讨我们的项目的改进之处:第二,探讨团队项目合作在前两个阶段存在的问题:第三,若是能够重新来过,我们应该如何改进或者如何避免这些问题. 首先,设想与目标方面,我们的项目是一个竞赛的

经常有创业公司老板来拜访我,常常会拜托给我一句话:帮我找一个CTO. 我解释的多了,所以想把这个写下来,看看你到底需要的应该是啥. 一.高级程序员 如果你是一个刚刚创业的公司,公司没有专职产品经理和项目经理,你就是公司的产品经理,你如果对你现在的开发员能力不满,那么你只需要的是一个高级程序员. 你定义功能.你做计划推进和管理,他可以带1-2个副手把你规划的功能实现了,他是主力干活者,有技术难题也是他来亲自攻克解决. 所以,一个高级程序员,他的职责很清晰: 1.负责核心复杂功能的实现方案设计.编码