精华内容
下载资源
问答
  • 稳定性全系列(一)——如何做好系统稳定性建设

    千次阅读 多人点赞 2019-12-24 00:49:37
    三、稳定性建设四要素 第一要素:人 第二要素:工具 第三要素:预案 第四要素:目标 四、稳定性建设四个方向 第一个方向:根基要抓牢(45%) 第二个方向:工作在日常(30%) 第三个方向:预案是关键(15%) ...

    目录

    一、背景介绍

    二、故障源的分类

    三、稳定性建设四要素

    第一要素:人

    第二要素:工具

    第三要素:预案

    第四要素:目标

    四、稳定性建设四个方向

    第一个方向:根基要抓牢(45%)

    第二个方向:工作在日常(30%)

    第三个方向:预案是关键(15%)

    第四个方向:容量是核心(10%)

    五、稳定性建设本质

    六、总结


    一、背景介绍

    在移动互联网时代,用户群的积累比之前更容易,但同样,也会因为糟糕的用户体验,而快速流失用户,哪怕是号称独一无二的12306网站,也在不断优化系统来提升用户体验;而在后移动互联网的物联网时代,软件工程师需要和硬件工程师配合,来保证提供的服务稳定和可靠。对,我们的产品就是为了实现用户价值,并提供非凡用户体验!

    如果说良好用户体验是增长的基础,那么良好的操作性、稳定的使用体验就是用户体验的基础,排除掉软件可操作性(这一块需要依靠专业的设计师),剩下的就是客户端(这里的客户端包括各种小程序、WebApp、H5页面等)和服务端,这一切都基于我们软件工程师来构建可靠、稳定的软件系统。 然而,随着我们服务的用户量越来越多,服务复杂度也越来越高,我们的系统为了可维护性,也会在业务架构和系统架构上进行调整,现在流行的微服务架构也因此应运而生。然而微服务架构也并不是没有副作用,例如它会增加维护成本和系统稳定性建设的成本。

    那么,什么是系统稳定性?这里我们引用百度百科的定义:系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。为了方便,本文阐述的系统主要指软件系统。那么如何衡量系统稳定性的高与低呢?一个常用的指标就是服务可用时长占比,占比越高说明系统稳定性也越高,如果我们拿一整年的数据来看,常见的4个9(99.99%)意味着我们系统提供的服务全年的不可用时长只有52分钟! 它其实是一个综合指标,为什么这么说?因为我们在服务可用的定义上会有一些差别,常见的服务可用包括:服务无异常服务响应时间低服务有效(逻辑正确)服务能正常触发等。

    二、故障源的分类

    系统的故障源一般可以分为两大类,一类是人为因素,另一类是自然因素

    常见人为因素导致的故障如下:

    人为因素我们要尽可能的事前(故障发生前)避免,因为这些原因引发的事故很可能会导致数据丢失或错乱、资金受损等较严重后果,而且除了重启或修复后重新上线外没有过多有效的止损手段。人为因素导致的故障往往会导致软件工程师的内心受到严重打击,工作和专业能力受到质疑,造成“人财两空”的后果,“我拼了老命来产出,结果却给自己挖了个坑”是故障责任人内心的真实写照。

    我们再来说说自然因素,自然因素受很多客观因素的影响,往往不受控制,无法避免。

    常见的自然因素导致的故障如下:

    自然原因导致的故障可大可小,虽然无法避免,但由于没有第一责任人,避免了“人性拷问”,软件工程师可以和运维部、安全部的同学协作起来处理故障。

    三、稳定性建设四要素

    “如果事情有变坏的可能,不管这种可能性有多小,它总会发生。”,残酷的墨菲定律预示着我们对自己系统提供的服务不要太乐观,接下来,我们说说如何建设系统稳定性,人为因素的根源一方面是专业能力不足,经验不足,另一方面很多都是无心之失,所以需要通过流程、规范来保住“底线”,减少人为因素导致的故障,而自然因素导致的故障往往具有突发性,需要联合多个团队协作来解决故障。

    稳定性建设四要素工具预案和目标

    第一要素:人

    我们先来说“人”这一要素,它需要回答如下5个问题:

    • 谁应该参与稳定性建设?

    • 如何降低犯错的概率?

    • 如何提高稳定性意识?

    • 如何定责?

    • 如何激励?

    稳定性建设工作需要老板支持,它的实施一般需要开发测试运维安全还有产品等同学参与,而且主导方应该是开发、测试和运维。确定了参与方后,就可以做关键的一步:“参与稳定性建设的每个团队都需要在OKR中背负一部分稳定性指标”,这也是为什么说稳定性建设工作需要老板支持,因为和绩效考核相关。

    稳定性工作,规范先行。OKR的部分只是让各参与方在稳定性方面工作的投入变成合规化,平时如何去参与稳定性建设还得“有迹可循”,对于开发和测试来说就是要根据公司的当前技术体系去建设开发规范提测规范测试规范上线规范、复盘规范等。我们拿和软件开发最相关的开发规范来说,开发规范是对开发人员的要求,让开发人员知道什么是必须要做的、什么是推荐的、什么是应该避免的。通常开发规范至少应该包括如下几个部分:

    编码规范:对外接口命名方式、统一异常父类、业务异常码规范、对外提供服务不可用是抛异常还是返回错误码、统一第三方库的版本、哪些场景必须使用内部公共库、埋点日志怎么打、提供统一的日志、监控切面实现等,编码规范除了能规范开发的编码行为、避免犯一些低级错误和踩一些重复的坑外,另一个好处是让新入职的同学能快速了解公司的编码原则,这点对编码快速上手很重要。这里再重点说一下为什么要统一异常父类和业务异常码,例如虽然不同模块(这里的模块指的是能独立部署的项目)可能有不同的异常父类,比如订单模块的异常父类是OrderException、交易支付模块的异常父类是TradeException,而OrderException和TradeException的父类是BizException(当然BizException是定义在一个通用共公共库中的),而我们也需要去统一异常码,比如200代表正确的返回码,异常的返回码是6位数字(前3位代表模块,后3位代表异常类型),有了统一的异常父类和异常码后,很多切面就都可以由公共库来做了,比如统一的监控、统一的出入口日志打印,统一的异常拦截,压测标识透传、特殊的字段埋点等,千万别小看这些,这些能在未来持续提升研发效率,降低稳定性工作成本。

    公共库使用规范:为了能对通用功能进行定制化改造和封装,公司内部肯定会有一些公共库,例如日志库、HTTP库、线程池库、监控埋点库等,这些库都“久经考验”,已经被证实是有效且可靠的,这些就应该强制使用,当然为了适应业务的发展,这些公共库也应该进行迭代和升级。

    项目结构规范:为了贯彻标准的项目结构,一方面我们需要为各种类型项目通过“项目脚手架”来创建标准的项目结构原型,然后基于这个项目原型来进行开发,统一的项目结构一个最显著的好处是让开发能快速接手和了解项目,这种对于团队内维护多个项目很重要,人员能进行快速补位。

    数据库规范:数据库连接资源堪比CPU资源,现在的应用都离不开数据库,而且通常数据库都属于核心资源,一旦数据库不可用,应用都没有太有效的止损手段,所以在数据库规范里,库名、表名、索引、字段、分库分表的一些规范都必须明确,这里特别提一点,就是分表数量不要用2的幂(比如1024张表,很多人认为使用2的幂分表数在计算分表时用位运算会更快,但这个开销相比数据库操作其实可以忽略),而应该用质数(比如最接近1024的质数应该是1019),采用质数分表数能让数据分的更均匀

    这会引发另一个问题,那就是我们有这些规范,那么如何让开发来知晓和遵守?一方面是设定合理的奖惩机制(例如由于没有遵守规范而引发的线上事故要严惩),另一方面就是——考试!没错,就是考试,将这些规范和历史的线上事故整理成试题,让新老开发定期去考试,考试是一种传统的考核机制,我们可以把规范和公共库的更新部分,也及时加入到考试试题中,来督促大伙及时学习。

    有了OKR、规范和考核机制,加上我们定期宣导,相信各成员的稳定性意识会有显著提高。

    事故定责一般是比较复杂的过程,除非事故原因非常简单明了,但实际上事故原因常常涉及多个团队,如果责任分摊不合理,难免会引发跨团队的争吵,合理的做法是引入第三方稳定性团队来干预,例如滴滴的星辰花团队,星辰花会撰写定责指南,并制定一些相关流程机制。

    当然,如果达成稳定性年度目标,也应该对这些团队进行适当表彰。

    第二要素:工具

    工具意味着手段,要做好稳定性建设,强大的支持工具和平台是不可缺少的,常见的工具和平台包括:日志采集分析检索平台(例如滴滴的Arius)、监控告警平台(例如滴滴的Odin Metrics)、分布式追踪系统(例如Google的Dapper、滴滴的把脉平台)、自动化打包部署平台(例如滴滴的One Experience)、服务降级系统(例如滴滴的SDS)、预案平台(例如滴滴的911预案平台)、根因定位平台(记录所有故障发生前所有系统变更事件)、放火平台等。

    强大的工具能回答如下3个关键问题:

    • 我们能做什么?

    • 我们能做到什么程度?

    • 如何降低稳定性工作成本?

    工具本质上是手段,它能降低我们在稳定性工作上投入的成本,例如有了监控告警平台,我们就不需要专人时刻盯着日志或大盘,有了分布式追踪系统,问题定位会更有效率,有了降级系统,一些故障能自动控制和恢复,不用我们再上线一次。要想做好稳定性工作,工具必不可少,没有工具,稳定性建设总是低效的。

    其实公司内建的公共库也属于工具的一种,像滴滴内部的公共库,业务系统接入Odin Metrics和把脉几乎不要做额外的工作(当然接入把脉需要提日志采集工单,头疼),千万不要吝啬在工具方面的投入,很多开源框架可以拿来用或拿来参考,工具和平台可以内部进行互通和联动,这样可以建成一站式的稳定性工作平台。

    第三要素:预案

    紧急预案是我们在故障发生时的行动指南,这在故障可能涉及到多个团队、故障进展需要周知到多个团队时特别有用。

    完善的紧急预案能回答如下4个问题:

    • 故障发生时我们该做什么?

    • 谁来指挥?

    • 谁来决策?

    • 我们如何善后?

    当一个不那么容易定位的故障发生时,你应该做的第一件事应该是什么?这在不同公司、同一个公司同一个团队的不同成员恐怕都会给出一个不同的答案,而在滴滴内部,我们大多会第一时间通知团队内其他成员、Leader(寻求帮助)和客服、上游业务开发等可能的影响方 (问题周知)。当这一步做完以后,一般就会有一部分同学加入问题排查和止损,然而介入的人多了,排查和止损的效率不一定会成比例的提升,这时候协调者很重要,协调者要避免介入的同学在做重复工作,协调者还需要持续和客服、上游业务开发等影响方沟通(我们曾经就经历过由于问题排查问题进度没有及时有效和业务方沟通,业务方将故障升级的case)。对于排查问题和止损的同学来说,要操作某个开关,有可能还要去查代码看开关的名字是什么,还有可能关掉一个功能需要操作多个开关,这些在紧急时刻都有可能由于慌乱而出错。而且什么条件下才能操作开关,谁能决定应不应该操作开关,恐怕在当时很难去做最正确的事情,而这一切,没错,都应该提前写到预案中!!!

    紧急预案一般要包含如下内容:

    1. 故障发生时应该通知哪些人或团队。

    2. 如何选出协调者,什么情况下该选出协调者。

    3. 协调者的职责有哪些。

    4. 需要操作开关时,谁有权利决策。

    5. 常见故障以及对应的止损方式。

    6. 止损的原则是什么,什么是最重要的。

    7. 善后方案谁来拍板。

    预案很重要,完备的预案能降低故障定位和止损的时间,提升协作效率。

    第四要素:目标

    如何衡量稳定性建设工作是有价值的?如何考核稳定性建设工作达没达标、做的好不好?这些都能在稳定性建设的目标中找到答案。

    稳定性建设的目标主要用来回答如下2个问题:

    • 稳定性工作的价值是什么?
    • 稳定性工作如何考核?

    稳定性建设工作的价值不仅需要团队所有成员认可,更重要的是需要老板的认可,没有老板的认可,稳定性建设工作只是团队内部的“小打小闹”,难以去跨团队来体系化运作。

    稳定性建设工作的年度目标可以拿服务可用时长占比来定,也可以拿全年故障等级和次数来定,像滴滴这边,星辰花将故障等级分成了P0至P5六个等级,P0、P1、P2属于重大事故,是需要消耗服务不可用时长的(根据全年定的服务可用时长占比指标来计算出某个部门的全年服务不可用总时长),一旦年底某个部门的全年服务不可用时长超过年初设定的阈值,就会有一定的处罚,并影响部门绩效(之前达标也有奖励,但后来奖励取消了)。

    这里做一个汇总:

    四、稳定性建设四个方向

    前面我们提到的稳定性建设工作的四个关键点,但对如何落地阐述的并不多,这里结合作者多年的稳定性建设工作经验,谈谈稳定性建设工作的四个方向。

    第一个方向:根基要抓牢(45%)

    稳定性建设工作重在预防,根据作者多年的工作经验,至少6成线上故障都可以在预防工作中消除,我们需要投入45%的精力来做根基建设,所谓根基建设,就是把开发测试上线这三大流程做透!!下面列了几个关键点:

    Code Review:CR其实是一个很重要的环节,当一个开发整个编码和提测都可以自己闭环搞定时,时间一长就容易产生懈怠,这时候写隐患代码的几率会大大提高,CR的过程并不是diss的过程,这个一定要在团队内拉齐,相反,CR是一次很好的团队沟通和塑造自己影响力的机会。我就很佩服那些代码写得质量高并且能把整个流程讲顺的人。我们团队的项目都接入了全流程(例如滴滴的鲲鹏),分支合master必须要其他人Review,但这是“离线”的,没有代码作者讲的过程,效果没有几个人坐在小黑屋讲的好,只是更快而已。我们团队规定,大于等于4人日的项目需要进行小黑屋CR。CR还可以让其他成员来检测该代码实现是否遵循了开发规范,毕竟“先污染后治理”的成本太高,记住,CR一定是一个相互学习的过程

    设计评审:再也没有比糟糕的设计更有破坏力的东西了,设计评审和CR可以放在一起做,先评审设计再进行CR,有人就会说,都编码完了才进行设计评审是不是晚了?其实这要看情况而定,如果团队内部经常产出“糟糕设计”,那么我觉得设计评审就应该编码之前来做,但如果团队成员专业能力和经验都还不错,那么我们允许你再编码之后再做设计评审,而且编码的过程其实也是设计的过程,可以规避提前设计而导致后续编码和设计不一致的问题。设计评审的原则是,既要讲最终的设计方案,也要讲你淘汰的设计方案!

    提测标准:写完代码就可以提测了?当然不是,至少得完成补充单元测试、完成自测、完成开发侧的联调、通过测试用例(如果QA提前给了测试用例的话)、补充改动点和影响点(便于QA评估测试范围)、补充设计文档(对,现在滴滴的QA养成了读代码、看设计的习惯)这些步骤才能说可以提测了。当然,提测标准理论上是QA同学来定义的。

    测试流程:测试的全流程覆盖最好能做到全自动化,很多测试用例可以沉淀下来,用来做全流程回归,当然这需要系统支持。我也见过太多犹豫QA没精力进行全流程回归而导致问题没有提前发现而产生的事故,所以测试的原则是尽可能自动化和全流程覆盖,让宝贵的人力资源投入到只能人工测试的环节。

    上线流程:上线也是一个风险很高的操作,我们简单统计了19年的上线次数,光我们团队负责的系统就上线了五百多次。部署平台需要支持灰度发布、小流量发布,强制让开发在发布时观察线上大盘和日志,一旦有问题,能做到快速回滚(当然要关注回滚条件)。我们这边的做法是先小流量集群灰度(我们把单量少的城市单独做了一套小流量集群),再线上灰度,确保哪怕出问题也能控制影响。

    第二个方向:工作在日常(30%)

    俗话说养兵一日,用兵一时,平日的养兵其实也非常重要,这一方向我们需要投入30%的精力,需要我们做到如下几点:

    人人参与:团队内人人都需要参与稳定性建设工作,稳定性工作不是某个人的事情,所以我会要求所有人的OKR中都有稳定性建设的部分。做toC研发的同学,都养成了带电脑回家的习惯,哪怕是加班到晚上12点,当然在外旅游也带着电脑,手机24小时保持畅通;稳定性已经成为了生活本身。

    持续完善监控告警:监控告警就是我们发现故障的“眼睛”和“耳朵”,然而大多数监控告警都需要我们手动一个个配置,随着业务的不断迭代,会有很多新接口需要添加监控,一些老的监控的阈值也需要不断调整(否则大量告警会让人麻木),所以监控告警是一个持续优化的过程。

    及时消灭线上小隐患:平日发现的一些问题要及时消灭,很多线上事故在事前都有一定预兆,放任平时的一些小问题不管,到后面只会给未来埋上隐患。

    跨团队联动:稳定性肯定不是一个团队的事情,一些降级方案可能涉及多个团队的工作,所以定期的跨团队的沟通会议是很有必要的,要大伙一起使劲才能把事情做好。

    复盘机制:对出过的线上事故一定要及时的进行复盘,通过复盘来发现我们现有流程、机制是否有问题,让大伙不要踩重复的坑,并不断完善我们的紧急预案。复盘虽然属于事后的行为,但很重要,我们需要通过复盘来看下次是否能预防此故障,或者是否能更快的定位和止损。

    会议机制:稳定性周会、稳定性月会,我们通过各种定期的会议来总结一些阶段性进展和成果,拉齐大家认知,这也是大伙日常稳定性工作露出的一个机会,所以非常重要。

    第三个方向:预案是关键(15%)

    我们通常都会忽视预案的作用,因为预案整理起来确实比较麻烦,预案也需要随着功能的迭代而不断更新,否则将很容易过时,而且预案在平日非故障期间也确实没有发挥作用的机会。但我们不得不承认紧急预案相当重要,特别是当我们去定位和止损一个比较复杂的线上问题时。

    我们需要在预案的制定和演练上投入15%的精力,可以从如下三个方面着手:

    分场景制定和完善紧急预案:如果我们还没有紧急预案,那第一步就是分类分场景整理下历史上经常发生的线上事故,例如MySQL故障预案、MQ故障预案、发单接口故障预案等。而且预案有可能会被多人查看,一定要清晰易懂,如果某些预案是有损的,需要把副作用也描述清楚。

    通过放火平台来验证预案:借助放火平台和服务降级系统,我们可以通过主动给主流程服务的非核心依赖注入故障,来验证系统在遇到非核心依赖发生故障时,核心服务是否仍旧有效,如果某些预案无法做成系统自动的(比如某些预案有一定的风险或副作用),也可以在预发环境来验证该预案是否能达到预期效果,防止真正故障发生时“手生”。预案就是在这种不断演练过程中来优化和完善的,这样的预案才是动态的,才是活生生有效可靠的!

    第四个方向:容量是核心(10%)

    我们知道木桶效应,一个木桶能装多少水取决于最短的那块板,在分布式系统中也是如此,我们需要摸到分布式系统中的这块“短木板”才能知道整个系统的吞吐量(容量),如果我们没有这个值,老板问你明年单量要Double,问你要预算,要规划你凭什么给?最准确的容量预估方案就是——线上全链路压测。至于滴滴是如何做线上全链路压测,后续我会有专门的文章来阐述。

    我们继续探讨容量这个话题,我们应该投入10%的精力来摸容量、扩容量、水位预警等。容量也相当重要,根据我的经验,线上有大约10%的故障和容量有关,当遇到这种问题,最有效的解决方案就是扩容!关于容量,我们在日常需要做到如下三点:

    常态化的全链路压测:线上全链路压测必须定期举行,特别的在有大促活动时,也需要提前进行一次。因为随着业务的快速迭代,系统老的瓶颈可能消失,新的瓶颈可能出现,所以之前的全链路压测的结果将失效,我们需要定期去摸这个线上环境的这个阈值。

    定期进行扩容演练:在滴滴内部,我们会定期进行弹性云扩容演练,这在紧急情况下很有用,我们就曾经遇到过弹性云扩容比修改阈值重新上线更快解决问题的case。

    多活建设:我们知道多活主要是为了容灾,但其实多活实际上也从整体上增加了系统容量,所以也属于容量扩充的范畴,一旦某个机房遇到瓶颈,我们可以分流到其他机房。当然多活建设需要一定成本,业务量大到一定程度才需要投入。

    说了这么多,我们也放张图来进行总结:

     

    五、稳定性建设本质

    就像我们做项目要“面向风险”编程一样,系统稳定性建设的目的其实就是为了应对未来的风险,和未来风险做对抗(哪怕我们有些手段将未来的风险变小)。如果非让我们探究稳定性建设的本质,我觉得稳定性建设的本质是将系统和系统间未来不可控的因素逐渐变为可预见,可控的因素,并着手去一一解决的一个过程。

    六、总结

    做稳定性建设一定要结合公司或组织的实际情况,量入为出,最合适的方案才是最好的方案。结合咱们上述讨论的几点,我们可以画出稳定性建设的房子,如下:

    希望我们能像建筑师一样,给业务构建一套稳定、可扩展、性价比高的房子!!!

     

     

    其他稳定性全系列文章:

    稳定性全系列(二)——如何做线上全链路压测 https://blog.csdn.net/manzhizhen/article/details/104439629

    展开全文
  • 服务端稳定性测试

    千次阅读 2019-05-12 20:48:05
    一、什么是稳定性 二、稳定性测试方法 方法一:线下稳定性测试通常的做法 关注指标: 测试注意事项 方法二:线上监控/线上巡检 三、故障模拟测试在提升系统稳定性中的实际应用 四、客户端稳定性测试 一、...
    展开全文
  • MATLAB的汽车操纵稳定性仿真分析

    千次阅读 2020-05-13 16:23:59
    因此,汽车的操纵稳定性日益受到重视,成为现代汽车的重要使用性能之一。 1 前轮转向车辆的操纵性能计算机模型 汽车以恒速行驶时,汽车只有沿y轴的侧向远动与绕z轴的横摆运动两个自由度。此外,汽车的侧向加速度...

    0 引言

    随着道路的改善,特别是高速公路的发展,汽车以100km/h或更高车速行驶的情况是常见的。现代轿车设计的最高车速一般常超过200km/h,有的运动型轿车甚至超过300km/h。因此,汽车的操纵稳定性日益受到重视,成为现代汽车的重要使用性能之一。

    1 前轮转向车辆的操纵性能计算机模型

        汽车以恒速行驶时,汽车只有沿y轴的侧向远动与绕z轴的横摆运动两个自由度。此外,汽车的侧向加速度限定在0.4g以内,轮胎侧偏特性处于线性范围。图1所示为一个由前后两个侧向弹性的轮胎支撑于地面、具有侧向及横摆运动的线性二自由度汽车模型,其运动方程为:

     

    2.3 稳定性分析

    通常,随着车速的提高,车辆的行驶稳定性下降。对具有过多转向特性的车辆而言,当车速超过其极限车速时,系统将处于不稳定工况,即意味着在很小的干扰输入时,系统将产生很大的响应输出(如高速转向时车辆可能发生侧滑)。而车辆行驶的稳定性与其等效线性系统的特征值有密切的联系。

    在MATLAB环境中有多种方法可以求系统的特征根(即极点),其中最直接的方法可调用eig()命令来求一个矩阵的特征值。由控制理论可知,一个可观、可控的线性系统的就是状态矩阵A的特征值,因此,求解车辆在不同车速(15~60m/s范围内)的特征根,同时在同一复平面中作图,可采用如下MATLAB程序段:

    U=15:5:60;
    
    for j=1:length(U)
    
    A=[-(Cf+Cr)/(M*U(j)) -(a*Cf-b*Cr)/(M*U(j))-U(j)
    
    -(a*Cf-b*Cr)/(Iz*U(j)) -(a^2*Cf+b^2*Cr)/(Iz*U(j))];
    
    plot(real(eig(A)),imag(eig(A)),'bx');
    
    hold on;
    
    end

    其中,命令语句real()和imag()分别用于系统特征值的实部和虚部求解。

    不同车速下的根轨迹变化如图4所示。

     

     

    展开全文
  • Redis 从入门到精通

    千人学习 2019-09-21 14:21:06
    随着移动互联网的发展,NoSQL 技术得到了快速发展,出现了例如 MongoDB、redis 等 NoSQL 数据库,其中 Redis 拥有出色的性能、丰富的数据结构和良好的稳定性、同时拥有分布式的架构等优秀特性得到了业界的广泛应用,...
  • 稳定性测试

    千次阅读 2018-08-28 17:04:00
    最近工作过程中没少开会,产品总监与研发总监就产品可用性和稳定性开始了一轮大战。 于是我搜集网络资源,罗列一些稳定性测试,只为分享。 1 关于软件稳定性测试的思路 如何测试软件的稳定性其实是很难的,按照...

    最近工作过程中没少开会,产品总监与研发总监就产品可用性和稳定性开始了一轮大战。

    于是我搜集网络资源,罗列一些稳定性测试,只为分享。

    1       关于软件稳定性测试的思路

    如何测试软件的稳定性其实是很难的,按照常规思路,只有长期的用户场景测试才能一定程度上保证软件的稳定性是可靠的,但并不能百分之百确定软件就是稳定的。软件测试本身就是由局限和尽头的,无穷的测试只能带来高成本的投入和无限期的计划延长。

     

    其实,可以从反面角度来看待软件的稳定性,我们从一个简单的数学定理入手:

     

    原命题成立,则逆否命题也成立。

     

    原命题:软件没有明显缺陷,所以是足够稳定的

    逆否命题:软件并不是很稳定,所以有明显的缺陷

     

    假设原命题是正确的,那么你否命题应该也是正确的。

     

    我们从原命题出发,很难说服团队去相信软件是足够稳定的,因为稳定的软件是没有明显缺陷的,没有数据的支撑和客观的事实,简单的例子就是,一我们不可能发现软件中所有的缺陷;二我们不可能花2~3个月不定地运行软件然后生成报告说经过长时间的实验软件十分稳定,时间不允许,就算时间允许我们也不敢保证3个月后程序是否还继续稳定如初。

     

    从逆否命题出发会简单许多,我们可以短时间内投入足够的精力去想办法证明软件很不稳定,比如让软件在高负荷下持续运行,给不同的压力和并发请求,进行破坏操作等等,如果软件没有出现明显的缺陷那么说明原命题也是成立的,从这个角度思考就可以从容地解决软件稳定性验证的问题。

     

     

    2       app测试--稳定性测试

    稳定性测试的概念有2种,

    一, 稳定性测试,对应于异常性测试,即发生异常情况时,系统如何反应的测试。包含:

      1 交互性测试,被打扰的情况,如来电,短信,低电量等。这些其实在上章的功能测试中有提到。

      2 异常性测试,断网,断电,服务器异常等情况

    二,稳定性测试指的是性能测试,压力测试

      1 基准性能测试,通过压服务器端口及客户端在不同网络环境下响应速度

      2 大数据测试,在特定环境下,客户端一次性更新大量数据及人员列表

    另有其它文章,提到性能测试,为评估APP的时间和空间特性(真是高深啊,时间和空间,再来个4维,5维?),包括:

      1 极限测试:在各种边界压力情况下,如电池,存储,网速等,验证app是否能正确响应

      --内存满时安装app

      --运行app手机断电

      --运行app时断掉网络

      这几点倒是与第一条的内容重复

      2 响应能力测试:测试app中的各类操作是否满足用户响应时间要求

      --app安装 ,卸载的响应时间

      --app各类功能性操作的影响时间

      3 压力测试:反复、长期操作下,系统资源是否占用异常

      --app反复进行安装卸载,查看系统资源是否正常(弄个几次就行吧,正常人,谁反复安装卸载啊)

      --其它功能反复进行操作,查看系统资源是否正常(这倒是应该的)

      4 性能评估:评估典型用户应用场景下,系统资源的使用情况

      这里要定义,什么是典型用户应用场景

      5 benchmark测试(基线测试),应该不是基准性能测试:与竞争产品的benchmarking,产品演变对比测试等(没有多大意义)。

    简要步骤:adb devices---了解包名--adb shell monkey -p 包名 -v 运行次数(多个参数的组合形成不同的用例以求最大的覆盖)--当崩溃或无响应时分析monkey日志

    常规monkey命令(可直接在项目里使用):

    adb shell monkey -p com.jiochat.jiochatapp --throttle 100 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 1000000>d:\b.log

    重现bug:monkey日志搜索关键词ANR exception,将之前的事件重新操作,尤其是seed值要一模一样,如monkey -p 包名 -v seed 0 500

    日志分析:查看是否有crash等关键字,找上下文,进行简单分析将你所能定位的错误信息发给开发。

    该工具用于进行压力测试。 开发人员结合monkey 打印的日志 和系统打印的日志,修改测试中出现的问题。Monkey 是SDK中附带的一个工具,所有的事件都是随机产生的,不带任何人的主观性。

     

     

    3       软件稳定性测试

    1 稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中,对系统施压,观察系统的各种性能指标,以及服务器的指标。

    2 测试场景:模拟平常的压力,模拟实际中日常的用户数进行操作。数据库要存有一定的数据。

    3 稳定性测试是概率性的测试,就是说即使稳定性测试通过,也不能保证系统实际运行的时候不出问题。所以要尽可能的提高测试的可靠性。可以通过多次测试,延长测试时间,增大测试压力来提高测试的可靠性。

    4 稳定性测试的测试时间和压力存在一定的关系。在测试时间不能保证的情况下,可以通过增强压力在一定程度上来挽救。

    观察系统的各种监控指标曲线,预测系统的发展状况。响应时间是否有增长,可用内存是否在减少,CPU利用率是否在上升等等都可以说明系统是否存在问题

     

     

    4       系统稳定性测试之基础知识

    一、定义     

    稳定性测试是在保证基本功能完整正确的前提下,软件或系统在一定时间或压力下,检验功能稳定运行的情况及性能优劣趋势,以减少系统或软件崩溃的发生。

     

    二、关注点

    稳定性测试直接的关注点,就是软件或者系统功能特别是用户常用功能的稳定性;其次关注的是性能指标的变化;在测试过程中,我们需要特别考虑多线程进程及不同测试环境问题。

     

    三、工作的内容

     

     

     

     

    5       软件测试---软件性能测试和可靠性测试

    1.软件性能测试的基本概念

     

    软件的性能是软件的一种非功能特性,它关注的不是软件是否能够完成特定的功能,而是软件在完成该功能时展示出来的及时性。

    (1)软件性能的指标

    1)响应时间:是指系统对请求作出响应的时间,并且这个时间被人们的接收程度是随着系统的不同而不同的(一个游戏相应3秒无法忍受,一个编译程序编译3分钟也是可以接受的)

    2)系统相应时间和应用延迟时间:前面的响应时间主要是指用户感受到的响应时间,其中还可以具体分为系统响应时间和呈现时间,性能测试比较关注系统响应时间

    而系统响应时间又可以具体分为网络传输时间和应用延迟时间,性能测试比较关注应用延迟时间

    3)吞吐量:吞吐量是指系统在单位时间内处理请求的数量,但是并不是访问人数越多吞吐量越高,因为随着访问人数的增多系统的可分配的资源会减少造成吞吐量下降等

    4)并发用户数:是指系统可以同时承载的正常使用系统功能的用户数,与1秒钟几十万吞吐量相比上千用户的并发量是一个更直观但也更笼统的性能指标

    5)资源利用率:反映在一段时间内资源平均被占用的情况

     

    (2)软件性能的角度

    用户视角:对于用户而言,性能就是响应时间,对于大量的数据,如果一边返回数据一边呈现对于用户而言响应时间也是很快的

    管理员视角:管理员可以通过使用软件提供的管理功能等手段来对系统性能进行优化,但是一般不涉及到源代码的修改

    开发人员视角:开发人员的角度和管理员的角度基本是一致的,但是开发人员更需要深入的关注软件的性能

     

    (3)性能测试的目标

    发现缺陷

    性能调优

    能力检验与规划

     

    (4)性能测试的分类

    性能测试

    并发测试

    压力测试

    可靠性测试

    负载测试

    配置测试

    失效恢复测试

    性能测试类型包括负载测试,强度测试,容量测试等。

    • 负载测试(Load Testing):负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标,譬如软件在一定时期内,最大支持多少并发用户数,软件请求出错率等,测试的主要是软件系统的性能。
    • 压力测试(Stress Testing):强度测试也就是压力测试,压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标,譬如在一定时期内,系统的cpu利用率,内存使用率,磁盘I/O吞吐率,网络吞吐量等,压力测试和负载测试最大的差别在于测试目的不同。
    • 容量测试(Volume Testing):确定系统最大承受量,譬如系统最大用户数,最大存储量,最多处理的数据流量等。

    性能测试中包含以下测试类型:

    • 基准测试 - 比较新的或未知测试对象与已知参照标准(如现有软件或评测标准)的性能。
    • 争用测试:- 核实测试对象对于多个主角对相同资源(数据记录、内存等)的请求的处理是否可以接受。
    • 性能配置 - 核实在操作条件保持不变的情况下,测试对象在使用不同配置时其性能行为的可接受性。
    • 负载测试- 核实在保持配置不变的情况下,测试对象在不同操作条件(如不同用户数、事务数等)下性能行为的可接受性。
    • 强度测试- 核实测试对象性能行为在异常或极端条件(如资源减少或用户数过多)之下的可接受性。
    • 容量测试- 核实测试用户同时使用软件程序的最大数量。
    • 性能评价通常是和用户代表一起协作并且以多级方法执行的。

    性能分析的第一级涉及单一主角/用例实例的结果评价和多个测试执行的结果比较。例如,在测试对象上没有其他活动的情况下,记录单一主角执行单一用例的性能行为,并将结果与相同主角/用例的其他几个测试执行进行比较。第一级分析有助于确定可以表明系统资源中存在争用的趋势,该趋势将影响从其他性能测试结果所得出的结论的有效性。

    分析的第二级检查特定主角/用例执行的摘要统计信息和实际数据值,以及测试对象的性能行为。摘要统计信息包括响应时间的标准偏差和百分位分布,这些信息显示了系统响应的变动情况,正如每个主角所见到的一样。

    分析的第三级有助于理解性能问题的起因和加权值。该详细分析采用低级数据并且使用统计方法,帮助测试员从数据中得出正确的结论。详细分析为决策提供客观和定量的标准,但是它耗时较长,并且要求对统计学有基本的理解。

    当性能行为差异确实存在,或是由于某些与测试数据收集相关的随机事件引起时,详细分析使用统计加权值的概念来帮助理解。即认为在基本级上,任何事件都具有随机性。统计测试确定是否存在无法用随机事件解释的系统差异。

     

    2.软件性能测试的执行

     

    与功能测试相比,性能测试更复杂,执行难度更大,对测试工具的依赖也更强,更需要过程模型的指导(如:PTGM性能测试通用模型)

    PTGM模型主要包括6个步骤:

    (1)测试前期准备,通常要求软件已经通过功能测试并修正了缺陷

    (2)引入测试工具

    (3)指定测试计划,需要明确性能测试的目标

    (4)测试设计和开发,准备好软件运行的软硬件环境,用户并发使用软件的测试场景,每个用户具体如何使用该软件

    (5)测试执行和管理

    (6)测试结果分析

     

    SEI负载测试计划过程:

    测试负载主要考虑一下六个方面

    (1)目标,指的是商业目标而不是技术目标,明确软件达到什么样的负载能力才能满足项目的商业目标

    (2)用户,是指可能产生负载或使用资源的人和软件过程

    (3)用例,是指用户对软件的不同使用方式

    (4)使用环境,软件在实际交付的运行环境中

    (5)测试环境,在测试中的环境

    (6)使用场景

     

    LoadRunner的性能测试过程:

    这是一个针对LoadRunner工具进行设计的测试过程,总体上是满足PTGM的

    (1)指定测试计划

    (2)设计测试用例

    (3)设计测试脚本(将测试用例转换成可以执行的测试脚本)

    (4)创建测试环境(测试脚本运行的测试环境)

    (5)运行测试脚本

    (6)分析测试结果

     

    3.性能分析

     

    (1)性能下降曲线的分析

    主要包括三个区间:性能平坦区,性能轻微下降区,性能急剧下降区

    (2)快速性能瓶颈识别:优先考虑吞吐量,优先考虑简单的测试用例,优先考虑基础系统的性能

    (3)性能计数器的分析:内存,处理器,I/O磁盘,进程等分析

     

    4.性能测试的自动化

     

    包括创建进程或者线程来模拟用户产生压力

    对性能进行监控

    对结果进行分析

    依赖一些性能测试工具

     

    5.软件可靠性的概念

     

    (1)错误,缺陷,故障和失效

    错误:指的是软件在生命周期中各个阶段的状态和行为与人们的期待不一致的偏差,不单单是软件系统本身,中间产品的偏差也算是软件错误

    缺陷:指的是软件中一切不好的方面,比错误的范围更广,如,一个不易理解的软件不是错误的,但是可以归为缺陷

    故障:是指软件代码中的错误

    失效:是指由故障引起的在软件运行期间的错误

     

    (2)软件可靠性的定义

    在规定的条件下,在规定的时间内,软件不引起系统失效的概率

    在规定的时间周期内,在所述条件下程序执行所要求的功能的能力

     

    6.软件可靠性测试的执行

     

    软件可靠性测试的目的是收集软件测试时揭示的软件故障的情况,并对其进行整理

    主要包括5个步骤:

    (1)确定可靠性目标

    (2)定义软件运行剖面

    (3)设计测试用例

    (4)实行可靠性测试

    (5)分析测试结果

     

    7.软件可靠性分析

     

    (1)失效模式影响分析

    (2)严酷度分析

    (3)故障树分析

    (4)事件树分析

    (5)潜在路线分析

     

    转载于:https://www.cnblogs.com/jianfeijiang/articles/9549465.html

    展开全文
  • 排序算法的稳定性及其汇总

    万次阅读 2018-10-31 19:59:58
    其中分组的合理会对算法产生重要的影响。现在多用D.E.Knuth的分组方法。 Shell排序比冒泡排序快5倍,比插入排序大致快2倍。Shell排序比起QuickSort,MergeSort,HeapSort慢很多。但是它相对比较简单,它适合于数据...
  • 软件稳定性测试

    万次阅读 2016-02-24 06:23:39
    稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中,对系统施压,观察系统的各种性能指标,以及服务器的指标。 2 测试场景:模拟平常的压力,模拟实际中日常的用户数进行操作。数据库要存有一定的...
  • python flask web开发入门与项目实战

    千人学习 2019-12-15 19:02:04
    可以带来系统稳定性和可扩展性的提升。Flask自由、灵活、可扩展性强、第三方库的选择面广,用第三方库可以实现自己想要的功能,而且很多第三方库还可以定制与裁减。       对于初学者来说简单...
  • 1.前言 我的毕设做的是基于opencv和卷积神经网络的人脸识别项目。...BN层加快网络训练速度和收敛时的稳定性。 加大网络深度,提高模型的特征抽取能力。 ** 3.卷积神经网络结构对比 **
  • 运放稳定性3:环路稳定性基础(3)

    千次阅读 2018-04-16 18:02:26
    作者:Tim Green,TI公司Burr-Brown 产品战略发展经理1.3 稳定性标准图1.14 的下部显示代表一个带反馈运放电路的传统控制环路模型框图;上部显示与控制环路模型相对应的典型带反馈运放电路。我们将这种带反馈运放...
  • 浅谈系统实现层面稳定性保障

    千次阅读 2021-02-23 16:20:00
    我个人加入阿里之初是在国际支付宝核心团队长期负责金融系统稳定性保障,其后扎根淘系技术三年有余,参与了多种不同类型系统设计与稳定性建设,以及大促稳定性保障工作。对比总结下来无论电商、金融、物流、ERP型...
  • 管理者如何保持团队稳定性

    千次阅读 2013-12-14 20:37:56
    以下就通过我个人在百度的经历,经验以及教训, 以及公司中的培训,说下我碰到的员工离职的原因, 以及在管理者能够操作的范围内,如何挽留员工,保持团队的稳定性及士气。 总结下来, 主要有两个因素影响员工...
  • Web应用架构演进 WEB应用架构演进过程,系统对于性能和稳定性方面需要解决的问题
  • 负反馈的稳定性

    千次阅读 2018-08-28 16:16:07
    负反馈的稳定性是一个很陈旧的内容。但实际上真正理清楚并不简单。最突出的一点是,模电教材上喜欢讲:负反馈系统传递函数,如果环路增益满足相位为180°,幅度为1,那么分母就是0,传函变成无穷大,电路开始自激...
  • 如何保障高并发系统的稳定性与高可用 文章来源:企鹅号 - 品质出行技术 要论如何搞垮一家互联网公司,速度最快的不是产品经理的胡乱决策,运营的无休止的烧钱,客服人员对客户的冷漠,一定是系统核心功能持续不可用...
  • 研发管理-稳定性风险治理

    千次阅读 2020-12-27 17:25:25
    研发管理-稳定性风险治理 前言: 在研发管理过程中,软件产品上线运行中,不可避免的会有很多故障问题,特别是新品上线。今年上线新品的时候,就出了很多故障,造成了很不好的影响,包括产品的和研发团队的和我个人...
  • 智能支付稳定性测试实战

    千次阅读 2018-12-14 11:01:10
    主要介绍了美团智能支付业务在稳定性方向遇到的挑战,并重点介绍QA在稳定性测试中的一些方法与实践。 背景 美团支付承载了美团全部的交易流量,按照使用场景可以将其分为线上支付和智能支付两类业务。线上支付,...
  • 区别系统的“稳定性、鲁棒性、与非脆弱性”(转载)
  • 以深度学习为代表的机器学习方法已经在计算机视觉、语音识别、医学影像分析、电子竞技等领域得到了成功的应用,其发展引发了学术界、工业界甚至政界的广泛关注。然而,现有深度学习方法的有效依赖于对训练数据集的...
  • 选择排序、快速排序、希尔排序、堆排序不是稳定的排序算法, 冒泡排序、插入排序、归并排序和基数排序是稳定的排序算法。 冒泡法: 这是最原始,也是众所周知的最慢的算法了。他的名字的由来因为它的工作看来...
  • 热爱java和一些函数式语言,长期关注系统稳定性领域 一、差旅随想 因为base在分公司,需要经常去总部出差,所以搭乘飞机成了家常便饭,很多时候坐在飞机上会不由的感叹,设计制造这样精密复杂的机器的那帮人真的是...
  • 一线工程师告诉你嵌入式真实现状与发展前景

    万次阅读 多人点赞 2018-10-02 18:49:59
    个人说明:本人并不是年薪百万的技术大牛,但总算是一名合格的嵌入式工程师,现在某企业担任嵌入式软件工程师开发一...百度搜索“嵌入式”、“嵌入式开发”、“嵌入式发展前景”等字眼,出来的都是一大堆培训机构,...
  • 卷积神经网络综述

    千次阅读 2019-02-25 14:51:38
    下面来简单介绍和归纳总结一下国内外卷积神经网络的结构,分析...卷积神经网络不仅具有传统神经网络的较好容错、自适应和较强自学习能力等优点,还具有自动提取特征、权值共享以及输入图像与网络结构结合良好...
  • 性能测试之稳定性测试

    千次阅读 2014-07-06 17:00:24
    (8)稳定性测试     1 稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中,对系统施压,观察系统的各种性能指标,以及服务器的指标。 2 测试场景:模拟平常的压力,模拟实际中日常的用户数进行操作。...
  • 2019工程伦理慕课答案(2019秋)习题及期末答案

    万次阅读 多人点赞 2019-11-08 18:19:53
    第一章习题(下) ... 自主 创造 社会 确定 多选题 (1points) 下列哪项是工程的完整生命周期中的环节 计划 设计 评估 完成 判断题 (1/1 point) 计划、设计、建造...
  • 可现实是,随着业务的发展,请求量会越来越高,进而各种系统资源得以激活,那潜在风险也会慢慢的暴露出来。 因此,做系统的难点之一便是:如何在高并发的条件下,保证系统的高可用。上文已经说了一些保证高可用的...
  • 软件测试工程师经典面试题

    万次阅读 多人点赞 2018-10-27 23:55:52
    前期面试实习生或者一年左右的岗位,问的也主要是一些基础的问题比较多。涉及的知识主要有MySQL数据库的使用、Linux操作系统的使用、软件测试框架的问题,测试环境搭建问题、当然还有一些自动化测试和性能测试的...
  • 浏览器性能和稳定性分析

    千次阅读 2014-03-18 15:47:37
    1. 在利用开源带来的优点的同时也要考虑开源项目的缺点:不稳定性,对于跟新比较快的项目,如何选择代码同步的策略和自家代码的合并方式也很重要。 2. 简化浏览器的界面,在UI方面对用户的行为做出适当的引导,...
  • 入门学习Linux常用必会60个命令实例详解doc/txt

    千次下载 热门讨论 2011-06-09 00:08:45
    因为Linux与Windows不同,其后台运行着许多进程,所以强制关机可能会导致进程的数据丢失,使系统处于不稳定的状态,甚至在有的系统中会损坏硬件设备(硬盘)。在系统关机前使用 shutdown命令,系统管理员会通知所有...
  • 美团智能支付稳定性测试实战

    千次阅读 2018-12-13 19:52:43
    总第313篇2018年 第105篇 本文介绍了美团智能支付业务在稳定性方向遇到的挑战,并重点介绍QA在稳定性测试中的一些方法与实践。如果你想学习互联网金融的技术体系...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 341,836
精华内容 136,734
关键字:

发展的稳定性