精华内容
下载资源
问答
  • 处理问题的思路和角度
    千次阅读
    2021-01-14 11:22:24

    几种分析的角度_分析,乃议论之本:给材料议论文写作导引

    2.几种分析的角度

    所谓分析的角度,就是分析问题的出发点。

    分析的角度有许多,这里我们选“条件分析”、“因果分析”、“演变分析”和“多角度分析”逐一加以介绍。

    (1)条件分析:就是从事物形成的条件、环境、背景等具体情况入手,进行分析。

    “世界上任何事物的存在都有一定的条件,任何事物都和它周围的某些事物有一定的联系,都不是孤立的。”那么,我们练习条件分析,就可以从事物的发生、发展、结果,去研究是哪些条件在起着影响、促进与制约的作用。

    以《驴子之死》为例,试作条件分析。

    驴子之死

    驴子驮着盐去渡一条河,它滑了一下,跌倒在水里,它站起来时轻了许多。这件事使它很高兴。后来有一回,它驮了棉花过这条河,当它走到河边时,以为跌倒在河水里,还可以比以前更轻地站起来,便故意一滑,跌倒在河里,可它不能再站起来,便淹死在那河里了。

    条件分析:

    驴子两次过河,两次跌倒在水里,为什么第一次能轻松地站起来,而第二次却淹死在河里呢?这就要我们从形成这两种截然不同的结果的条件、环境、背景等具体情况入手,进行分析:同一头驴子,两次过的是同一条河,所不同的是它两次驮的物质不同,一次是盐,另一次是棉花。我们知道,盐是可溶物质,而棉花却是非溶解物,不但不溶于水,还会吸水呢。第一次驮着盐,跌倒在河里,大量的河水足以溶解驴背上所驮的盐,盐溶于河水的同时就流失了,当然驴背上的重量会大大地减轻,驴自然会轻松地站起来;而第二次驴子驮的则是棉花,再跌倒在河里,即使河里水再大,也溶不了棉花呀,相反,倒是足够供棉花吸水到饱和的程度。这样一来,驴背上的棉花,由于吸收了大量的河水,怎么能不大大加重驴背上的重量呢?自然驴子会被压得一蹶不起,只落个葬身河底的可悲下场。显然,这驴子是弄巧成拙,葬送了自己的生命。而造成这悲剧的症结就在于无知的驴子只知其一,即跌倒在河水里会轻松地站起来,却不知其二,即跌倒在河水里之所以能站起来的缘由。可见,驴子是把自己仅知道的“其一”当成了宝贵的“经验”。于是就盲目套搬起“经验”来。滥用“经验”,可就成了“经验主义”了。经验主义者,没有不吃大亏的。如果驴子懂得了“经验主义的危害甚大”和“具体问题得具体分析”的话,那么,它若有第二次生命,再有机会驮着海绵和糖过河的话,就定会牢记惨痛的教训,定会恰到好处地选用自己曾获得的宝贵经验与教训,而绝不会重蹈覆辙,从而确保自己立于不败之地。可见,驴子是地道的“经验主义”的牺牲品。故事的寓意:告诫人们“经验主义危害甚大,具体问题得具体分析”这一真谛。这一番分析实属条件分析。

    (2)因果分析:就是从现象发生的原因入手,或事物之间的因果关系入手,进行分析。

    世界上万事万物之间存在着千丝万缕的各种联系,其中十分重要的一种,便是因果联系。辩证唯物主义指出:“因果联系是客观世界普遍联系和相互制约的表现形式之一。”自然界和社会任何一个或一些现象,都会引起另一个或另一些现象的产生;反过来,任何现象的产生也都是由其他的现象所引起的。其中,引起一定现象的现象是原因,由于原因的作用而产生的现象是结果。因果联系的特点之一,是原因在先,结果在后。由于客观事物的联系是极其复杂的,因此事物的因果联系也是复杂多样的。从原因来讲,有主要原因和次要原因,直接原因和间接原因等。从结果来讲,又有主要结果和次要结果,直接结果和间接结果等。我们分析事物,当然是从主要原因(或直接原因)和主要结果(或直接结果)入手,也就是要抓住真正的因果关系。这样,才有利于揭示事物的本质。

    以《新婚拒绝多置家具》为例,试作因果分析。

    新婚拒绝多置家具

    法国科学家居里夫人,新婚时竟拒绝父亲为她多置家具。她的婚室里只有一张床,两把椅子。这在一般人看来属于“傻冒儿”,财产还怕多吗?终身大事,能这样寒酸吗?然而她有她的理论:家具多了,得擦洗、掸刷,而她“没有这个工夫”。原来,她把“工夫”全用在实验室里。她发现了一种新元素“镭”,她一连四十五个月不分昼夜,从两千多吨矿石、水和药品中提炼出一克纯“镭”。从此,“镭的母亲”的荣耀称号传遍了全世界。

    因果分析:

    法国科学家居里夫人获得了“镭的母亲”的荣耀称号,并被传遍了全世界。也许,你会觉得她很幸运。是的,她的确很幸运,因为她是个成功者。但请你一定要在觉得她很幸运的同时,深刻地意识到:任何发明创造的产生都须要付出艰辛的劳动,都须要付出很大的“工夫”,“功到自然成”么。所以,幸运是和付出成正比的。如果我们只看到成功的荣耀,却忘掉了成功者为此而付出的代价,显然不能正确地评价科学史上的发明创造。居里夫人之所以成为幸运的成功者,就是因为她为此付出了四十五个月的不分昼夜的艰辛劳动,不,准确一点说,是她慷慨地付出了不计其数的“工夫”。而她的“工夫”又是从哪里来的呢?正是来自“她竟连出嫁时父亲为自己盛情多置的家具都拒绝了”这样的令人费解的举动上。其实,就是她把别人擦洗、掸刷家具的工夫都用在科学实验上了。可见,她在处理家务之类的生活琐事上所花的工夫是多么的吝啬呀!但必须明确没有为生活所花工夫的吝啬,就不会有为科学而付出毕生的工夫的慷慨,也就不会有事业上的成功,因为“成功需要付出”。显然,我们是从这成功与付出两者之间的关系入手,进行因果分析的。(www.guayunfan.com)

    (3)演变分析:就是从事物的发展、变化入手,进行分析。

    演变分析有两个特点:第一,以事物的发展、变化状况作为分析的对象;第二,通过对事物的发展、变化状况的研究去认识事物的特点、本质和意义。世界上的万事万物,就像川流不息的江河,永远处于不停的运动之中,“一切皆变,无物常住”。因此,“要用发展的眼光看问题”。即学会用发展的观点认识事物。

    以《球王贝利》为例,试作演变分析。

    球王贝利

    有这样一段记载:当球王贝利踢进1 000个球时,记者去访问他:“您对所踢进的1 000个球中的哪个最满意?”贝利回答:“我对1 001个球最满意。”

    演变分析:

    看了这段记载,首先,感到球王就是球王!贝利之所以能成为球王,那是因为他在过去的足球赛中连连获胜,即所谓“连冠”,而之所以能连冠,是因为他过去一直是不断奋发,不断进取,从不满足;从他回答记者的话:“我对1 001个球最满意”来看,无疑,他现在仍然一如既往地不满足现状,在他的潜意识里,一定是认为踢进的1 000个球只代表过去的成绩,而第1 001个球则代表未来的成绩。可见,“任何成果都不是最后的”是他的座右铭。因为,他懂得在竞争激烈的今天,球坛的比赛亦如逆水行舟,“不进则退”。要赢对手,要想永远立于不败之地,只有永远是以未来的最佳成绩的获得为奋斗目标。显然,贝利是用发展的观点看球坛的激烈竞争的。而我们对贝利的观点的分析,理应采用演变分析。

    总之,条件分析、因果分析及演变分析是互有联系而又互有区别的。它们都是以事物的发展、变化为分析对象。但是分析角度全然不同:条件分析着重研究形成事物发展、变化的条件;因果分析着重研究形成事物发展、变化的原因及这个发展、变化会导致怎样的结果;演变分析则着重研究事物发展、变化的实际状况和支配这种发展、变化的动力与规律是怎样的。

    (4)多角度分析:我们研究某一个问题,从一个角度做过分析之后,再从另一个角度做一下分析,或者将两种角度结合起来,进行分析,这样从两个以上角度来分析问题的做法,就叫做多角度分析。

    因为任何事物都有它形成的过程,也都有它形成的条件与原因,任何事物的发展演变都是在一定的条件下发生的,也都有它一定的原因,因此,要想深入地认识事物,就须要学会从多方面去了解事物,研究事物,这就是要掌握多角度分析的本领。

    以《教书先生智斗吝啬富翁》为例,试作多角度分析。

    教书先生智斗吝啬富翁

    相传有一位吝啬富翁,聘请了一位教书先生。他对这位先生说:“膳食供给非常微薄。”在这种情况下,教书先生借口说空口无凭,便和富翁立了一个合约:“无鸡鸭亦可无鱼肉亦可青菜一碟足矣。”富翁在上面欣然签了字。哪知第一顿饭,教书先生就大喊大叫起来:“我们不是约定说有荤菜也有素菜嘛,怎么今天全是素菜呢?”只弄得富翁哭笑不得。

    多角度分析:

    我们看了这个故事后,首先发现的就是教书先生与吝啬富翁所立的合约没有标点,抓住这个线索进一步琢磨,就发现这合约有两种不同的读法:其一是“无鸡鸭亦可,无鱼肉亦可,青菜一碟,足矣。”其二则是“无鸡,鸭亦可;无鱼,肉亦可;青菜一碟,足矣。”显然教书先生是准备以后一种读法,来为自己争得应得的待遇的,而吝啬富翁却随心所欲地理解为是前一种读法。因为,这正满足了他那吝啬的心理。这一番分析,明显的是以事物形成的条件、环境、背景等具体情况入手,进行条件分析的。如果分析到此结束,就只能将寓意理解为:相同的字样,标点不同,表达的意思也就大不相同了。而这样的寓意只能告诫人们:“标点很重要,要学会准确地使用标点。”如果以这个寓意来立论,未免太肤浅了吧!看来,要想提炼出一个有深层含义的论点,对于这则材料的分析,只从条件分析的角度去分析,是远远不够的。我们不妨再从另一角度去深入分析一番吧:面对这有歧义的两种读法,教书先生之所以能如愿以偿的选择有利于自己的一种,是因为他正是这有歧义的读法的标点的设计者,真可谓是位称职的“设计师”了!别忘了,他之所以设计得如此专业,是因为他是个教书先生,他具备这方面的知识。可吝啬富翁就不然了,他拥有的却只是所谓的“万能的钱”和吝啬的本性,而对于知识,他几乎是个“绝缘体”!若不是吝啬心理作祟的话,恐怕连“其一”也不知道,更不用说那“其二”了。否则,他怎么会在合约上欣然签字呢?而后又怎么会被弄得哭笑不得呢?所以,与其说是教书先生战胜了吝啬富翁,倒不如说是知识战胜了愚昧与无知。显而易见:“知识就是力量。”分析到此,我们终于满意了。因为我们挖掘出的寓意是极深刻的。而这样有深度的寓意的取得,显然是由于我们从条件分析的角度入手分析后,又从另一个角度,即因果分析的角度去推进分析的结果。这就是多角度分析的功劳了。不难看出:“多角度分析”对议论文的“层递型”尤为适用。

    看来,只有掌握好分析的角度,才有助于打开分析的思路,从而入手分析并推进分析,使分析逐步深入。这样,分析才中肯,才能切中要害,才有利于挖掘出有深度的寓意来。

    但是,不论是采用哪一种角度的分析,也不论是展开分析,还是推进分析,都得靠“提出问题,给予解答”的分析的基本方法来进行。

    更多相关内容
  • 本文希望以一个用户请求为线索,将整个用户侧到服务器至存储层整个链路给串起来,从全链路到角度尽可能通俗的谈一谈各个部分的一些优化思路和自己的思考,笔者水平有限,有些思路也还没有经过大流量的检验,对于一些...

    这是一篇什么文章?

    本文希望以一个用户请求为线索,将整个用户侧到服务器至存储层整个链路给串起来,从全链路到角度尽可能通俗的谈一谈各个部分的一些优化思路和自己的思考,笔者水平有限,有些思路也还没有经过大流量的检验,对于一些大佬来说可能本文不能让你眼前一亮,在此就可以return了。

    为什么会写这么一篇文章?

    先说一说我的情况吧,目前大四在读,通信工程专业,学校算不上很好吧,普通一本罢了,上了大学以来,对计算机就挺感兴趣的,对于本专业的一些课程,像模拟电路,通信原理等提不起太大的兴趣,于是在业余时间,自己学习计算机相关的东西,大一大二时以学习python为主,学习了爬虫,自动化,机器学习,深度学习等等,当时是想着毕业后搞人工智能方面的工作,自己也玩过一些demo,像猫狗识别啊,NLP等等,不过其实都是很浅显的部分。后来了解到人工智能这玩意好像挺看重学历的,而自己的学历本身不出众,所以放弃了,大二结束的暑假转而学习后端开发的技术栈,当时学习的语言是Java,为什么选它呢?当时是觉得Java的就业人员虽然多,但是就业机会也是最多的,并且网上的资料也是最全的。当时也没有想过进什么大厂之类的,就凭借着自己的一腔热情在学。

    时间到了大三下学期开学,当时春招也开始了嘛,试着投了几家,有幸拿到了两家大厂一个实习机会,实习了几个月又开始秋招,也是受打击的一次,最开始蛮顺利的,三家大厂都是技术面➕HR面都面完了,然后等这三家的结果,结果一家都没等到,不知道是学历的原因还是哪一面没答太好(个人猜测是横向对比排掉了),也情绪低落了两天吧,不过总是要站起来的,这也是我觉得秋招比考研更好的一点,考研一年只有一次,但秋招大厂有很多,同一家大厂也不只 一次机会,就接着面嘛。最后还是拿到了几家大厂的意向,目前在鹅厂提前实习。来了公司之后也学习了很多,很多的内部资源,真的有很多大佬,所以写一篇文章也是对我这么久以来的一些知识做一个总结吧。

    本篇文章图不多,因为懒。

    从用户侧说起

    当时年少不太懂啊,学java不久那段时间遇到这个问题我可能会说,这有啥好说的,不就是一个dns解析,拿到ip,然后就到服务器了嘛。

    其实这玩意还真有些可以优化的点,为什么这么说呢,首先最极致的性能就是没有网络开销,也就是浏览器缓存,直接在客户端就做了,但是这么做不可靠啊,万一数据有变更不就是旧数据了嘛。是这样,所以所谓的浏览器缓存并不是什么都不做,http请求的请求头信息其实有很多,服务器可以设置资源的过期时间,或者说服务器在响应一个资源时添加了ETag字段,那么当下一次浏览器会先发一个请求判断资源有没有过期。当然这其实不是很常用,这儿就浅说一下。

    然后是DNS这一层,浏览器得把域名解析成ip嘛,可是这里可能存在本地DNS缓存了失效的ip,域名劫持等问题哦,也可能存在本地运营商DNS偷懒把解析请求发给其他运营商, 导致全局调度器搞错浏览器的运营商造成跨网访问的问题。

    关于跨网访问这儿可以说一下,简单来说服务器是也是有运营商出口的,所谓的三网服务器就是有电信,移动,联通的出口,只要你的网络是这三个运营商的都不需要跨网,但是三网服务器贵啊,一般的服务器可能只有电信或者联通的,而跨网就是说你访问服务器会到 国家级互联网骨干直联点 进行一个转化,简单来说就是绕路了。
    这里挂一张 国家级互联网骨干直联点 图
    在这里插入图片描述
    那么这怎么解决呢,其实在浏览器上还真不好解决,不过到客户端上就好解决了,用httpdns就能很好解决了,httpdns简单来说就是将DNS解析发http请求找公司自己建的dns服务器,不走本地运营商的DNS了。这时候就能拿到用户真实的信息,实现最优的一个调度。

    不过用户到服务器的这一段是最不可控的,只要请求到了服务器,那么这个请求就是可控的了,而且内网的速度可是比公网快很多的。那么我们就得想办法减少这个不可控的范围。那么如何减少这个距离呢,用CDN就好了。

    CDN又叫内容分发网络,简单来说就是在全国各大城市建一个CDN服务器,那么用户请求只需要请求离他最近的CDN服务器不就好了,CDN有什么用呢?

    1. 可以做静态资源的加速,也就是说把一些静态的资源放到CDN上,请求到CDN这一层就返回了,而且还可以做动态的一个加速,比如我们为了安全使用https协议请求,那么到CDN这一层是不是就可以把tls卸载了?走http或者rpc请求到服务器上。如果想要加速得更多的话有钱的公司甚至会搭专线,这可比走公网快多了。
    2. CDN也可以让我们的服务器更加安全,为什么?因为除了CDN谁也不知道我们服务器的真实IP了呀。
    3. 请求聚合也算是CDN的一个优势吧,比如大量访问同一份资源请求miss了,那么CDN是不是只用发一个请求到服务器去拿数据就好了?有条件的公司甚至会设置多级CDN,如果资源miss了一层层回源,尽可能减少到服务器的请求。
    4. 连接聚合,CDN也能够自己管理大量的连接,服务器则只需要管理自己和CDN的连接就好了。
    5. 边缘计算了,我们可以把一些计算的逻辑放到CDN上。

    总的思想就是在离用户近一些的地方做更多的事情,CDN近几年的发展也是非常迅速,像现在还有PCDN,SCDN等。

    ps: CDN 无论是浏览器还是客户端的请求都可以加速,客户端可以走httpdns调度到离用户最近的CDN,浏览器走传统的DNS也可以通过CNAME调度到CDN。

    谈服务器之前先说一说网络协议吧

    现在大多数网站应该还是http1.1吧,http我们知道是基于tcp的,先说一说tcp的优化思路吧。

    • tcp首先需要三次握手才能建立连接吧,第一次握手的服务器会把这个连接放在半连接队列里面,等到三次握手完了之后就会把这个连接放到全连接队列里面,然后等到accpte来取连接就好了。但是当遇到syn攻击时可能导致半连接队列被打满,后续的连接服务器就会拒绝了。这时候就可以聊一聊tcp 的 syncookie了,简单来说就是服务器不会保持这个连接到半连接队列,而是计算一个cookie给客户端,第三次握手的时候客户端带上这个cookie,服务端验证这个cookie的有效性,如果合法再分配专门的数据区进行处理未来的TCP连接。并且只要在cookie的有效期内,下一次连接无需三次握手就可以直接连接了,这是不是就省时间了?
    • 再说到tcp的流量控制,大家知道tcp都有一个发送窗口和接受窗口是吧,那么我们可以根据服务器的性能设置一个合适的窗口大小,尽可能提高带宽吧。
    • tcp是发一个包有一个ack,要是等到ack来了再发下一个包可就耗时长了,于是就有了累计应答这么一说,客户端不必再等待ack直接发下一个包,服务端可进行累计应答,如果有丢包通过sack告知客户端是哪个包丢了就行了。
    • tcp拥塞控制都知道吧,最开始窗口大小是指数增长,到了ssthresh就开始线性增长了,直至发送拥塞,可是这传统的cubic算法有一个问题,就是一旦发生丢包就要拥塞避免,虽然现在有快恢复,但是发送速率还是有一个明显的下降。其实丢包不一定就说明是拥塞了,可能有很多原因,交换机有自己的队列控制算法(codel),大家有兴趣可以自行了解,于是有大佬提出了BBR算法,即通过一段时间内的最小延时和最大带宽来计算发送效率,尽可能保证带宽跑满。
    • 最后到四次挥手了,time_out状态大家都不陌生吧,服务器可能由于time_out状态太多而导致无法建立新的连接了,linux其实有一个参数tcp_tw_reuse可以复用time_out的连接,前提是得打开tcp对时间戳的支持。

    这些优化可还不够,我们知道http1.1是一问一答的形式,这就会造成典型的队头阻塞问题,并且每个请求可能会带上重复且臃肿的header,于是http2诞生了,简单说它对header进行了压缩,并且将header和body分成单独的流,通过流id进行区分,解决了队头阻塞问题,可是http2是基于tcp的,所以这还是存在tcp层次的队头阻塞,于是google再次提出了http3(QUIC)协议,它是基于UDP的,并在此之上实现了滑动窗口,拥塞控制,可靠性保证等等,彻底解决了队头阻塞。可是实际应用上这儿会有一个问题,就是大量UDP的包可能导致频繁的用户态到内核态的切换,其实可以考虑搞一个环形的缓冲区,牺牲一定的延时来提高吞吐量,减少两态的切换。

    接下来是不是就该到服务器侧了?

    请求或许通过层层CDN最终到达了我们的入口服务器,这个入口的服务器或许是开源的LVS+Keepalive 或者 Nginx来做负载均衡,也可能是公司自研的负载均衡器,nginx大家都知道性能很高,为什么呢?,首先他使用了epoll这个就不说了,这是内核提供的高性能网络处理技巧,nginx请求的切换是基于用户态的,同时nginx基于一把全局锁避免了epoll的惊群,nginx的work数量一般与cpu核心数相同,并且每个work与cpu绑定,提高了cpu cache的命中率,像一些数据结构也适用了内存对齐的技巧,让cpu只需要去内存取一次(cpu cache line),其他的一些技巧像连接池啊,高效的内存管理啊这里就不细谈了。

    总之这里就是一个大流量入口加负载均衡功能,这儿说两个优化的点,我们知道当服务器收到请求后,这个请求一般会跑一遍内核的网络协议栈,那么我们是不是可以把负载均衡的逻辑放在软中断里面?这不就避免了用户态和内核态的频繁切换了吗?或者我们能不能让这个网络包直接在用户态进行处理?没错,这就是intel的DPDK技术。DPDK已经可以让性能达到千万级别了,但这其实对CPU还是有很大的压力,那么能不能把这些操作放到网卡层面?其实是可以的,现在已经有了智能网卡了,简单来说就是网卡里面其实是有CPU的,它可以处理这些网络操作,不用占用应用层的CPU,不得不感叹现如今硬件的强大啊。

    请求下一个到达的地方是微服务网关(有些公司会把流量网关和微服务网关合到一起,例如阿里的云原生网关),微服务网关的目的是为了做一些横切面的功能,如鉴权,风控等,同时把后端的所有API信息聚合到一起,方便管理。微服务网关还有一个重要的功能,就是协议转换,比如我们可以把http请求转换成性能更好的rpc请求。rpc框架有很多,开源的thrift,dubbo,grpc等等,还有很多自研的,核心就是解决了服务发现,超时重试,负载均衡等等基础功能,提供SDK给业务层使用。

    说到RPC就不得不提到序列化,我是比较喜欢protobuf这种序列化的,它不仅性能高而且它是强约束的,因为PB文件是严格定义了接口的格式的,我们不需要写接口文档了(这是松约束的),统一把PB文件管理到版本控制系统如git,看PB文件就相当于看接口文档,而且它一定是最新的,不会像接口文档一样有可能过时。

    聊聊服务注册和发现

    服务发现是一个老生常谈的话题了,现在大部门公司的应用都是微服务架构了,那么服务注册与发现一定是避不开的,所有微服务启动时一定会在注册中心进行注册,然后RPC调用的时候也会去访问注册中心进行服务发现。现在开源的组件也很多,但都是围绕CAP理论来的,像典型的AP系统Eureka,分布式协调鼻祖ZK,新生代ETCD,Consul,阿里开源的Nacos等等,也很很多公司选择自研,像Eureka这种集群是没有master的,它牺牲了一致性,保证了可用性,就是说每个节点都有全量的一个信息,这种模式的好处就是不怕高QPS,如果抗不住了水平扩容就行了,缺点就是存在存储瓶颈,一旦元数据过多那么单台机器就存不下了,并且可能数据不一致,节点变更信息需要一段时间才能同步到全部节点。那么像ZK,ETCD这种有主的缺点也就呼之欲出了,高频的写入问题,可能让master宕机,当然存储瓶颈也是存在的。

    大家有没有发现一个问题,客户端是直接与存储的节点打交道的,就是注册中心既要处理服务注册与发现的请求,又要存储元数据。诶,提到这儿大家是不是就想到了,我们可以将存储和计算进行分离嘛!存算分离我个人理解应该是一个大的趋势。

    没错,我们可以把计算节点单独拎出来处理这些发现和注册的请求,计算节点是无状态的了,是不是可以很方便扩缩容了?并且存储的节点由于不知道跟客户端打交道,像一些数据的迁移呀客户端基本无感。但大家有没有想一个问题,服务发现的请求是不是应该比服务注册的请求高几个数量级?没错大部分的请求应该都是服务发现的请求,那么我们可以做一个隔离,服务注册由一些节点完成,注册由一些节点完成,注册节点甚至可以直接写DB,异步同步到缓存(比如通过canal),因为并发量其实并不高,而像服务发现可以读缓存,健康检查呀则可以写缓存。有的朋友可能会问了,只写缓存不写DB吗?我们可以异步写DB嘛。比如把写请求发送到消息队列里面,然后由消费节点写DB,这样一是避免了与DB的直接依赖,二是可以聚合请求嘛,减小DB的压力。

    那到来的每一个请求服务发现都查缓存吗?可不可以做个本地的缓存嘛,是不是又快了?编解码会耗cpu吧,那能不能缓存序列化好了的数据呢,这样下次请求来直接返回,无需序列化了。当然这么做可能会有一些时效性的问题,不过RPC框架也会有一些健康检查的机制,并且由于下游是多个节点,这个不通换一个不就好了,我个人觉得这是可以接受的。

    写到这里突然由想到了一个解决方案,RPC框架拿到下游服务的信息,一般会进行健康检查,如果发现有连接失效了,可以给注册中心发一个请求,告诉它这个服务失效了,并把这个失效的ip带过去,注册中心首先比较本地缓存,如果一样说明本地缓存过期,然后读缓存,如果缓存过期的话,我们可以读DB,但这样与DB有依赖了,我个人觉得DB同步到缓存应该是很快的,canal是通过binlog的嘛。要不要读还是得具体情况来权衡吧,架构设计不就是不断权衡的嘛~哪有什么完美的解决方案。

    聊聊RPC

    现在的微服务大部分应该都是容器化部署了,并通过k8s来进行调度吧,这个架构的优点就是可按需部署,且弹性伸缩,微服务本身其实并没有什么好说的,k8s的话说起来有一点庞大了。云原生时代的三驾马车之一的service mesh对传统的rpc其实造成了一定的冲击,service mesh通过sidecar的形式部署一个数据平面(envoy)与微服务在同一个pod中,rpc调用这个数据平面就能帮我们做了,不过这其实多了两次转发(一来一回),性能有一定损耗,虽然现在做了很多优化,但也许还需要时间的考验。我们这儿只专注于rpc来聊聊,rpc最重要的功能就是服务发现了,这个其实上面也谈到了,这儿就不说了。

    我们来聊聊超时控制,当然,我们希望的是一个全局的超时控制,这就需要比如从网关层算起,每到一个服务计算当前剩余超时时间和当前调用下游设置的最大超时时间中取一个最小的,然后rpc调用时把这个剩余超时时间给传递下去,这就可以做到一个全局的超时控制了。

    然后是过载保护,我们可以通过滑动窗口统计一段时间内进程的负载情况,cpu,内存等使用情况,然后计算出一个负载情况,如果负载过高,对于后面的请求直接拒绝掉,避免进程挂掉。 那么对于调用方来说,我们是否可以拿到下游的负载信息,然后基于负载做一个最优的rpc负载均衡调度呢(传统的轮询,随机等由于不知道下游情况可能造成下游负载不一致)。这个该怎么拿,一是调用下游的时候返回可以携带一些信息,二就是隔一段时间问一下嘛。当然这些都是rpc框架要做的,业务应该是无感知的。

    业务优化

    请求从网关侧离开就会到达我们的微服务了,也就是业务侧,业务优化这里简单说几个思路

    1. 避免长时间的锁占有和大量的锁争夺。
    2. 尽量用cas替代锁,因为锁是会陷入内核态的,而cas是基于硬件的指令,不会到内核态,底层是怎么做的各位有兴趣可以看看MESI(缓存一致性)的设计。
    3. 批操作,提高吞吐量。
    4. 池化技术,使用内存池,线程池,连接池等等。
    5. 零拷贝技术,内存映射。
    6. 异步化,可以异步操作的时候尽量不要同步。
    7. 流水线,尽量让每个步骤都忙碌起来,提高cpu整体的利用率。
    8. GC 优化,减少垃圾对象

    存储层

    存储是一个很大的话题啊,有最常用的关系型数据库mysql,oracle等,缓存redis ,memcache等,文档型数据库mongodb,面向搜索的存储es,OLAP数据库clickhouse,海量存储Hbase,分布式数据库TiDB,分布式文件存储HDFS,到现在很火的对象存储,块存储,数据湖解决方案。实在是太多了。虽然这么多存储方案,但大家有没有想过,它们的索引的数据类型就那么几个,有B+树,B树,跳表,Hash表,倒排索引,字典树,LSM树。大家有兴趣可以了解一下这些数据结构的应用场景。

    先说一说最通用的文件存储吧,我们知道一般文件系统为了加快IO的速度,一般都会是有自己的缓存的,也就是page cache,像一些零拷贝技术啊,也是直接把数据写到这里面去的,然后通过DMA控制器将数据写到磁盘,其实这儿也有一些IO调度策略,尽量一次性多写一些数据,提高吞吐量,而为了提高并行度,也可以用到RAID这样的技术,但其实这儿还是存在用户态到内核态的切换,为了解决这个问题,于是有了SPDK技术(类似于DPDK),其实就是把这些IO操作全部放到用户态来做。

    再谈一下大规模分布式存储吧。

    大规模的分布式存储一般有几个特点,一是数据海量,二是数据冗余(这是为了保证可靠性),三是优先写日志,因为写日志是顺序写,比较快。可是当数据量大到一定的级别就会出现元数据膨胀的问题,如果将元数据存在像ZK啊,ETCD啊这类的地方,肯定是不行的,一个节点内存撑死也才多大,像Eureka这种AP的系统也是不行的,虽然它可以抗住大量的并发(水平扩容),但是每个节点也会存在全量的数据,这可放不下啊。那么咋办。

    有句话说的好,遇到解决不了的问题,加一层代理。即我们可以通过元数据分级,缩减元数据量来解决,一层存放元数据的逻辑卷映射,一层存放逻辑卷物理地址的映射,有点类似于HBASE的ROOT表和META表的思想,同时为了减少元数据的读写负载,可以给元数据也加一层缓存,其次我们可以把一些数据校验,修复,均衡的工作分离成独立的节点,各个节点只专注于自己的工作,且按需扩容,避免节点的任务繁杂,彻底解决了单master的瓶颈。

    至于写日志,大部分分布式系统都是先写日志,在写磁盘,大家有没有发现这两个东西是不是有点耦合了,我们能不能把写日志的这个功能交给其他节点去做呢,即有单独的日志节点,它只负责写日志,我觉得这种方案最大的一个好处就是解耦了,由于日志节点不直接和业务相连接,对于像一些日志迁移啊基本对业务无感。

    当然还有更厉害的,忘记是哪位大佬说过的一句话了,“日志即数据”,我们甚至可以把日志当作可靠的数据来看待。不过这种方案实际上用起来可能没那么简单吧,哈哈,不过也许也会是一个不错的思路呢。

    展开全文
  • 【测试】定位bug的思路和方法

    千次阅读 多人点赞 2021-05-14 20:59:30
    0)定位原因之前保存bug产生的记录:排除低级问题:排除数据问题(脏数据):1)定位问题思路*判断是否为bug的标准:排查顺序:1.1 用户环境层面1.2 用户展示层1.3 逻辑控制层1.4 服务层1.5 数据库层*1.6 经验法则...



    为什么定位问题如此重要?

    • 可以明确一个问题是不是真的“bug”。很多时候,我们找到了问题的原因,结果发现这根本不是bug。原因明确,误报就会降低
    • 多个系统交互,可以明确指出是哪个系统的缺陷,防止“踢皮球”,提高问题解决的效率
    • 增强开发对测试的信任度,沟通更有效,配合的更好,开发修改bug时效增强。
    • 更有效的了解系统的内部逻辑、数据流处理流程,更能提高测试人员的水平,缺陷修复后,影响的测试范围评估更精准,复测更准确
    • 可以降低缺陷率。这个可以说是最重要的。在bug系统中,会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识,才会判别出开发写的是不是真正的原因,也才能有助于我们后续对bug进行分析归类,根据bug分析,有针对性地未雨绸缪,进而提升产品质量,降低缺陷

    0)定位原因之前

    遇到问题时,先别急着去定位原因。

    • 保存bug产生的记录:

      首要做的是保存bug产生的记录,保证可以复现

      • 为什么要保存记录?因为如果以后不能复现,那就不能证明bug的存在。
    • 排除低级问题:

      然后是排除QA的低级问题 。常见的低级问题:

      • 【hosts不对】
        • hosts文件主要是加快某个域名或者网站的解析速度,从而达到快速访问的作用。也可以屏蔽网站。
        • hosts异常可能会导致部分网页无法访问,能够加载,但是网页无法正常显示。
      • 【网络不通】
        • 抓包、ping
      • 工具的影响导致的,例如fiddler
      • 以及操作姿势不正确等。
    • 排除数据问题(脏数据):

      有时候会遇到服务端报500错误,查看日志后,报空指针,那么很有可能就是数据库中关联表的数据被人为删掉导致的。

      • 脏数据:从目标中取出的数据已经过期、错误或者没有意义,这种数据就叫做脏数据。
      • 脏读:读取出来脏数据就叫脏读。

    1)定位问题的思路

    *判断是否为bug的标准:

    • 功能是否符合需求说明书
    • 从使用者的角度:功能是否易操作、易理解
    • 系统压力指标是否达到质量要求
    • 排查顺序:

      用户环境层面 -> 展示层面 -> 逻辑控制层面 -> 服务层面 -> 数据库层面

    1.1 用户环境层面

    主要是指基础环境是否可以使用。比如:

    • 网络是否ping通
    • ip和端口配置是否正确
    • jdk版本是否符合标准
      • 有可能是由于jdk版本不兼容导致系统运行异常,这种问题根据实际情况来决定要不要兼容。
    • 网络设了代理
    • 弱网(如js/css未加载完全、请求超时)
    • 浏览器不支持
    • 系统版本不支持
    • 数据库被删除
    • 测试环境脏数据
    • 项目配置开关
    • 测试环境切了分支等

    检查完成后,可以转到第二步。

    1.2 用户展示层

    用户在使用过程中,通过查看等操作发现的一些问题:

    • 页面样式(css样式问题)
    • 交互过程中js的提示(js交互问题)
    • 终端控制的提示信息
    • 文本的展示(html文本问题)

    比如字段长度控制为4位,输入5位时,无法输入,或者大于4位页面弹出提示不允许输入大于4位。

    这种问题不通过与服务器的交互,由页面、终端直接控制。这种问题往往比较容易修改,检查后,进入到第三步。

    1.3 逻辑控制层

    用户操作过程中,业务的处理逻辑有没有按照前期的设计实施。或者中间环节出现异常,比如缓存服务器(如redis)、消息中间件(如rabbitMQ)、数据存取中间件等。

    比如我们使用的贷记卡日累计额度为1万,当消费大于1万时,检查通过

    • 经过排查,后台参数配置的不对,或者通过查代码发现该逻辑没有判断

    再比如多系统交互时,我们发送一个请求后,终端返回超时

    • 这个时候需要查看日志定位具体哪个系统有问题,这种需要查看每个系统的日志请求及响应
    • 如果没有系统返回超时,并且每个系统都收到了正常的响应,那可能是终端超时时间设置的时间过小,未等到返回先超时导致。

    该层的问题定位,一般都需要查看日志。该层检查完,转到下一层。

    1.4 服务层

    服务层往往检查服务器的配置,如可能是tomcat配置、nginx配置、jdbc配置等的问题。测试人员最好能够了解下它们的各项配置。

    比如发现内存溢出问题。

    • 那么可能是tomcat配置错误
    • 遇到过一个实际情况,应用系统为分布式部署,4路部署,当用户登录系统时,有的用户可以登录,有的无法登录,也不报错。经过逐层排查,发现有2路部署jdk版本不一致,原来用jdk1.6(2路),部署的为1.8(2路),是环境人员部署大意导致。

    类似问题可能还有tomcat版本等、jar包版本测试环境和正式环境不同。

    1.5 数据库层

    可能出现测试环境和正式环境数据库版本不同,前后端数据格式、长度限制不同。

    用户操作完成后,交易流程非常顺畅,这样也不代表整个交易没有问题,还需要测试人员检查数据库登记的表和字段是否正确

    • 如果发现登记的字段与预期的结果不一致,则可以查看日志,检查请求报文送的字段是否正确,是否与前台填写的一致。
    • 有的一个操作会登记多张表,所以要检查多张表登记或者更新的是否正确,测试人员也需要对被测系统的数据表结构熟悉。

    *1.6 经验法则

    有经验的测试人员对于有部分bug已经见过多次,能够很快找到根源,直奔主题,迅速报告或者解决bug。

    *1.7 其他

    常见的bug可能还有构建方面的原因

    • 比如代码本身没错,但是合并代码到主干后出现了问题。
    • 比如代码存在冲突时手动解决的情况。

    2)定位问题的方法

    2.1 常用的定位策略:

    常用的定位策略分为三类:原始类(brute force)、回溯类(backtracking)、排除类(causeeliminations)。

    • 原始类定位方法

      原始类定位方法是最常用也是最低效的方法,只有在万般无奈的情况下才使用它。

      • 主要思想是“通过计算机找错”。
      • 例如输出存储器、寄存器的内容,在程序安排若干输出语句等。
      • 凭借大量的现场信息,从中找到出错的线索,虽然最终也能成功,但难免要耗费大量的时间和精力
    • 回溯法

      回溯法能成功地用于程序的排错。

      • 方法是从出现bug征兆处开始,人工地沿控制流程往回追踪,直至发现出错的根源
      • 不幸的是程序变大后,可能的回溯路线显著增加,以致人工进行完全回溯到望而不可及。
    • 排除法

      基于归纳和演绎原理,采用“分治”的概念。

      • 首先确定所有与bug出现有关的所有数据,设想一个导致bug的原因,用这些数据证明或反驳它
      • 或者一次列出所有可能的原因,通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端,则立即精化数据,乘胜追击。

    上述每一类方法均可利用一些测试工具,开发工具。

    • 目前,调试编译器、动态调试器(追踪器)、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。

    2.2 查看状态码

    • 4xx状态码:

      • 4xx状态码一般表示是客户端问题(当然也有可能是服务器端配置问题)。比如:
        • 发生了401,那么要看下是否带了正确的身份验证信息。
        • 发生了403则要看下是否有权限访问。
        • 404则要看下对应的URL是否真实存在。
    • 5xx状态码:

      • 5xx状态码则一般表示服务端出现问题。比如:
        • 发生了500错误,则表明是服务器内部错误,这个时候要配合服务器log进行定位。
        • 发生了502错误则可能是服务器挂了导致的问题。
        • 发生503错误可能是由于网络过载导致的问题。
        • 发生504错误则可能是程序执行时间过长导致超时。

    2.3 查看服务器日志

    如果发生5xx问题,或者需要检查后端接口执行的sql是否正确,我们最常见的排查方法就是去看服务器日志,比如tomcat日志。

    • 开发人员一般会打出关键信息和报错信息,从而找到问题所在,所以,测试人员也要养成看日志的习惯。

    2.4 检查配置

    很多时候,bug不是代码的问题,而是tomcat配置、nginx配置、jdbc配置等的问题。

    • 在这个层面上,测试人员最好能够了解下它们的各项配置,在发现问题后可能就会想到这方面的问题。

    2.5 查看需求文档

    有时候,前端和服务端的交互都正确,但是从测试的角度看不合理。这个时候,我们应该翻翻需求文档。

    • 如果和需求文档不符,那么就要看下改什么比较合理,是改前端,还是改服务端,或者两者都要改。
    • 这里有一个原则,就是前端尽可能少地去承担逻辑,只负责渲染展现。

    当然,不要以为需求文档就全部正确,它也可能会有错误,我们也应该去发现需求文档的bug,然后再去协调PM,敦促FE或者RD进行修改

    2.6 向开发寻求可测性支持

    有时候,涉及到开发过程的一些测试,也需要开发提供可测性支持。

    • 比如,要查看接口给另一个接口发的请求是否正确,可以让开发打印出完整的请求log。
    • 还有一些逻辑开关、修改页面数据条数等,都属于可测性支持的范畴。

    3)bug定位常用工具

    • Firefox——firebug、web developer、live http - headers、http fox
    • IE插件——httpwatch
    • 第三方工具——fiddler
    • 慢速网模拟工具——firefox throttle

    4)如何区分前端/后端bug?

    *为什么要区分前端/后端BUG?

    • 如果是一个多人开发的系统,不能明确定位到这个bug是谁造成的,容易提交给错误的开发人员
    • 同时提交给前后端开发人员,每个人都会有依赖心理,bug会像皮球一样被开发踢来踢去,耽误开发解决bug的时间
    • 另外,如果团队规模较大,或者由各地的项目组拼凑而成,势必会增加沟通成本,这更需要我们在类似禅道或者Jira等项目管理软件中提交bug时,先指明是谁的bug,避免互相踢皮球的现象。
    • 所以测试必须要自己学会区分出是前端还是后端bug,经过bug分类处理,整个团队的效率都会有所提高

    *前后端BUG各有什么样的特点?

    前端Bug后端Bug
    界面相关业务逻辑相关
    布局相关性能相关
    兼容性相关数据相关
    交互相关安全性相关

    4.1 利用抓包工具来进行分析

    一般有httpwatch,firebug,fiddler,charles等抓包(数据包)工具。

    • httpwatch,firebug都是浏览器的插件,需要额外下载。
    • fiddler,charles也需要额外下载安装包另行安装。

    还有一个简单实用并的抓包工具,那就是浏览器的F12调试器

    • 浏览器F12调试器是所有浏览器内置的调试器,不需要额外去安装,而且它提供的功能也比较强大。
    • 如果测试web系统,可以先考虑使用这个调试器去抓包,用它来协助定位系统中的bug。
    • 在NetWork中可以看到当前页面发送的每个http请求。

    4.1.1 分析角度

    利用抓包工具,可以从三个方面进行分析:请求接口、传参、响应。

    • 请求接口:

      如果请求的接口url错误,为前端的bug。
    • 传参:

      如果传参不正确,如pn、ps参数,为前端的bug。
    • 响应:

      如果响应内容不正确,为后端bug。
      • 要继续深挖,是接口吐数据的时候出错了,还是数据库中的数据就错了,还是缓存中的数据错了(如果用到了缓存的话)。

    假设有这么一种情况,要测试一个翻页控件,翻到第二页的时候,发现内容和第一页完全一样,接口请求返回的是200。

    • 这个时候就要看前端发送的参数正不正常,后端返回的内容正不正常,即接口的请求和返回
    • 如果JS基础比较好的话,也可以在浏览器的控制台中输入JS代码进行调试

    4.1.2 F12调试器工具的使用

    1、打开:

    以火狐为例,打开浏览器,再按F12就可以打开调试器:
    在这里插入图片描述

    • 不同的浏览器,调试器在ui上可能会有少许差异,但基本功能都差不多。

    2、控制台与网络

    在分析一个系统bug来自于前端还是后台时,最有用的两个是调试器提供的两个标签,这两个标签底下都记录了一些数据,一个是控制台,一个网络

    • 控制台(Console):
      记录了前端js执行的情况,以及前端向服务器发出去的所有http请求信息
      • 如果有js错误,可以在控制台下看到。如果发现js执行报错了,那就是前端有问题,比如跨域问题。
      • 如果发送到后台的某个http请求没有得到服务器正常响应,也能看到其状态信息。
    • 网络(Network):
      记录了前端往服务器发的所有的http请求信息,而且每个请求发送了什么数据,服务器是否正常响应了请求。如果响应了,响应回来的状态码是什么,响应数据是什么,都可以在“网络”标签下看到。

    4.2 定位前端的bug

    前端的bug通常是功能、界面和兼容性等有关,涉及到jstl,jsp,js,css,html方面比较多。

    bug主要有两块:

    4.2.1 JS相关:

    第一就是JS写的有问题,这个可以按F12 打开控制台,在console中查看报错信息,一般浏览器都会显示报错的js 。

    • 对于出错的js可以在Sources下查看对应报错的资源文件,基本上都会找到错误原因的变量未定义,参数未定义等,JS错误都很好解决的。

    4.2.2 页面:

    第二个就是页面中的bug了,现在做web项目基本上没有做静态页面的,都是动态了,所以页面中要么使用了小脚本要么使用了EL表达式来存值。

    • 页面报错的话,在控制台是可以看到错误行号和附近代码的。
    • 图片不显示
      • 谷歌浏览器右键点击图片,点击【检查】,(火狐浏览器右键点击【使用firebug查看元素】。
      • 在打开的控制台上找出图片的属性,输入到浏览器的地址内,如果能打开图片,那么不显示图片的问题就是后台的问题。
      • 如果浏览器内不能打开图片,那么就是前端的问题

    4.3 定位后端的bug

    后台涉及到servlet,jms,ejb,还有很多框架,struts,hibernate,spring,ibatis等。

    • bug 比较难改,但是好找。主要就是看控制台报错,然后定位错误行号
    • 如果配置文件没有问题,那么一般的报错就是空指针,或者是数组下标越界。
    • 看附近变量,看方法的参数基本上都可以定位错误。

    4.3.1 查看报错日志

    日志常见的问题:

    命令行ssh/xshell工具登录到服务器,找到相应log日志所在的目录,实时查看日志 tail -f xx.logcat xx.log |grep '关键词' ,如找到报错信息可以去代码里面查是哪块报错。

    • 编码问题:
      tomcat是新的,需要改编码。修改tomcat的server.xml文件<Connector port="8080" URIEncoding="UTF-8"/>,特别是windows下的项目重新部署到linux系统下。
    • 空指针:
      程序问题,一般没有考虑到空的情况,或者主外键约束数据为空,或者删除关联数据,导致为空。
    • 长度过长:
      超过最大长度,测试环境修改数据库字段长度后生产环境未修改,导致错误。
    • 非法数据
    • 内存溢出:
      导致重启。

    4.3.2 查看数据库的数据

    了解所测功能的数据表结构,测试过程中,查看数据库的数据,确认数据的正确性。

    响应中有数据,但是跟自己操作的结果不一致,可以根据数据库查询,如果数据库中也没有记录,可能是代码有问题,没有记录你的操作。

    • 例如:注册了一个帐号,但是登录时提示帐号或密码错误,这就可以在数据库表中查看是否有注册的数据。

    4.3.3 查看缓存

    查看缓存(如Memcache、apc、redis等缓存)是否正确。


    5)定位完问题后

    在发现问题或者定位到问题原因后,一定要进行一步,就是再次确认问题

    • 所谓确认问题,就是弄清楚问题是否每次都发生,还是概率事件,或者是工具相关的问题
      • 比如换个浏览器是否依然出现?如果换个浏览器不出现的话,很可能就是前端的兼容性问题。
      • 比如翻页控件,待测的系统有很多页面都有翻页控件,那么就要看下是否每个页面都会出现这个问题,进而报bug时进行统一说明,也更加方便开发人员批量处理,防止漏改。


    【部分内容参考自】

    • 聊聊-如何准确定位bug原因:https://cloud.tencent.com/developer/news/44973
    • 10大定位bug原因妙招分享,软件测试人员必看:https://baijiahao.baidu.com/s?id=1634223794115270596&wfr=spider&for=pc
    • 三种bug定位方法:https://www.jianshu.com/p/4dbe0a194036
    • 定位bug方法及案例分享:https://www.jianshu.com/p/c0328eabd9a9
    • Web测试中定位bug方法:https://www.cnblogs.com/loved-wangwei/p/8985751.html
    • Web测试中定位bug方法:http://www.51testing.com/html/69/n-3722469.html
    展开全文
  • 数据分析的六种方法论八种思路

    千次阅读 2020-03-04 16:03:05
    这说明缺少理论知识的支持,那么本文就将盘点一下数据分析常用的方法论和思路,作为数据分析入门的基础。 数据分析的流程 在介绍数据分析方法论和思路之前,我们还是先不厌其烦地看一下数据分析的流程,简单来说...

    估计很多人都听过数据分析,但是真正做起来却不是那么一回事了。要么胡子眉毛一把抓,要么无从下手。这说明缺少理论知识的支持,那么本文就将盘点一下数据分析常用的方法论和思路,作为数据分析入门的基础。

    数据分析的流程

    在介绍数据分析方法论和思路之前,我们还是先不厌其烦地看一下数据分析的流程,简单来说分为以下六个步骤:

    1、明确分析的目的,提出问题。只有弄清楚了分析的目的是什么,才能准确定位分析因子,提出有价值的问题,提供清晰的指引方向。

    2、数据采集。收集原始数据,数据来源可能是丰富多样的,一般有数据库、互联网、市场调查等。具体办法可以通过加入“埋点”代码或者使用第三方的数据统计工具。

    3、数据处理。对收集到的原始数据进行数据加工,主要包括数据清洗、数据分组、数据检索、数据抽取等处理方法。

    4、数据探索。通过探索式分析检验假设值的形成方式,在数据之中发现新的特征,对整个数据集有个全面认识,以便后续选择何种分析策略。

    5、分析数据。数据整理完毕,就要对数据进行综合分析和相关分析,需要对产品、业务、技术等了如指掌才行,常常用到分类、聚合等数据挖掘算法。Excel是最简单的数据分析工具,专业数据分析工具有FineBI、Python等。

    6、得到可视化结果。借助可视化数据,能有效直观地表述想要呈现的信息、观点和建议,比如金字塔图、矩阵图、漏斗图、帕累托图等,同时也可以使用报告等形式与他人交流。

    数据分析方法论

    数据分析的方法论很多,小编为大家介绍其中六种比较常见的理论。

    1、PEST分析法

    PEST,也就是政治(Politics)、经济(Economy)、社会(Society)、技术(Technology),能从各个方面把握宏观环境的现状及变化趋势,主要用户行业分析。

    宏观环境又称一般环境,是指影响一切行业和企业的各种宏观力量。

    对宏观环境因素作分析时,由于不同行业和企业有其自身特点和经营需要,分析的具体内容会有差异,但一般都应对政治、经济、技术、社会,这四大类影响企业的主要外部环境因素进行分析。

    政治环境:政治体制、经济体制、财政政策、税收政策、产业政策、投资政策等。

    社会环境:人口规模、性别比例、年龄结构、生活力式、购买习惯、城市特点等。

    技术环境:折旧和报废速度、技术更新速度、技术传播速度、技术商品化速度等。

    经济环境:GDP 及增长率、进出口总额及增长率、利率、汇率、通货膨胀率、消费价格指数、居民可支配收入、失业率、劳动生产率等。

    2、5W2H分析法

    5W2H,即为什么(Why)、什么事(What)、谁(Who)、什么时候(When)、什么地方(Where)、如何做(How)、什么价格(How much),主要用于用户行为分析、业务问题专题分析、营销活动等。

    该分析方法又称为七何分析法,是一个非常简单、方便又实用的工具,以用户购买行为为例:

    Why:用户为什么要买?产品的吸引点在哪里?

    What:产品提供的功能是什么?

    Who:用户群体是什么?这个群体的特点是什么?

    When:购买频次是多少?

    Where:产品在哪里最受欢迎?在哪里卖出去?

    How:用户怎么购买?购买方式什么?

    How much:用户购买的成本是多少?时间成本是多少?

    3、SWOT分析法

    SWOT分析法也叫态势分析法,S (strengths)是优势、W (weaknesses)是劣势,O (opportunities)是机会、T (threats)是威胁或风险。

    SWOT分析法是用来确定企业自身的内部优势、劣势和外部的机会和威胁等,通过调查列举出来,并依照矩阵形式排列,然后用系统分析的思想,把各种因素相互匹配起来加以分析。

    运用这种方法,可以对研究对象所处的情景进行全面、系统、准确的研究,从而将公司的战略与公司内部资源、外部环境有机地结合起来。

    4、4P营销理论

    4P即产品(Product)、价格(Price)、渠道(Place)、推广(Promotion),在营销领域,这种以市场为导向的营销组合理论,被企业应用最普遍。

    可以说企业的一切营销动作都是在围绕着4P理论进行,也就是将:产品、价格、渠道、推广。通过将四者的结合、协调发展,从而提高企业的市场份额,达到最终获利的目的。

    产品:从市场营销的角度来看,产品是指能够提供给市场,被入们使用和消费并满足人们某种需要的任何东西,包括有形产品、服务、人员、组织、观念或它们的组合。

    价格:是指顾客购买产品时的价格,包括基本价格、折扣价格、支付期限等。影响定价的主要因素有三个:需求、成本与竞争。

    渠道:是指产品从生产企业流转到用户手上全过程中所经历的各个环节。

    促销:是指企业通过销售行为的改变来刺激用户消费,以短期的行为(比如让利、买一送一,营销现场气氛等等)促成消费的增长,吸引其他品牌的用户或导致提前消费来促进销售的增长。广告、宣传推广、人员推销、销售促进是一个机构促销组合的四大要素。

    5、逻辑树法

    逻辑树又称问题树、演绎树或分解树等。它是把一个已知问题当成“主干”,然后开始考虑这个问题和哪些相关问题有关,也就是“分支”。逻辑树能保证解决问题的过程的完整性,它能将工作细分为便于操作的任务,确定各部分的优先顺序,明确地把责任落实到个人。

    逻辑树的使用必须遵循以下三个原则:

    要素化:把相同的问题总结归纳成要素。

    框架化:将各个要素组织成框架。遵守不重不漏的原则。

    关联化:框架内的各要素保持必要的相互关系,简单而不独立。

    6、AARRR模型

    AARRR模型是所有运营人员都要了解的一个数据模型,从整个用户生命周期入手,包括获取(Acquisition)、激活(Activition)、留存(Retention)、变现(Revenue)和传播(Refer)。

    每个环节分别对应生命周期的5个重要过程,即从获取用户,到提升活跃度,提升留存率,并获取收入,直至最后形成病毒式传播。

    数据分析思路

    数据分析方法论主要是从宏观角度介绍如何进行数据分析,它就像是一个数据分析的前期规划,搭建一个清晰的数据分析框架。那么对于具体的业务场景问题,就要靠具体的分析方法来支撑了,下面小编就介绍几种常用的数据分析思路。

    1、趋势分析

    最简单、最常见的数据分析方法,一般用于核心指标的长期跟踪,比如点击率、GMV、活跃用户数。可以看出数据有那些趋势上的变化,有没有周期性,有没有拐点等,继而分析原因。

    2、多维分解

    也就是通过不同的维度对于数据进行分解,以获取更加精细的数据洞察。举个例子,对网站维护进行数据分析,可以拆分出地区、访问来源、设备、浏览器等等维度。

    3、用户分群

    针对符合某种特定行为或背景信息的用户,进行特定的优化和分析,将多维度和多指标作为分群条件,有针对性地优化供应链,提升供应链稳定性。

    4、漏斗分析

    按照已知的转化路径,借助漏斗模型分析总体和每一步的转化情况。例如将漏斗图用于网站关键路径的转化率分析,不仅能显示用户的最终转化率,同时还可以展示每一节点的转化率。

    5、留存分析

    留存分析是一种用来分析用户参与情况/活跃程度的分析模型,考察进行初始行为的用户中,有多少人会进行后续行为。衡量留存的常见指标有次日留存率、7日留存率、30日留存率等。

    6、A/B 测试

    A/B测试是为了达到一个目标,采取了两套方案,通过实验观察两组方案的数据效果,判断两组方案的好坏,需要选择合理的分组样本、监测数据指标、事后数据分析和不同方案评估。

    7、对比分析

    分为横向对比(跟自己比)和纵向对比(跟别人比),常见的对比应用有A/B test,A/B test的关键就是保证两组中只有一个单一变量,其他条件保持一致。

    8、交叉分析

    交叉分析法就是将对比分析从多个维度进行交叉展现,进行多角度的结合分析,从中发现最为相关的维度来探索数据变化的原因。

    展开全文
  • 模型优化中常见问题和解决思路,包括过拟合、欠拟合等问题
  •  目前面对网络建设逐步完善,4G用户的不断发展,针对零流量小区的分析及处理存在着必要性。零流量小区的分布既是用户分布及行为的直观体现,也是用发展用户的一个指引,同时也能发现设备的一些故障。一个站点的能够...
  • 角度人脸识别简单介绍

    千次阅读 2018-08-18 10:44:13
    实际上,当人脸角度和采集的角度比较一致(角度较小的偏转)时,才有较精确的结果。 关键点: 1、2D图像导致人脸比对困难。 2、如何使人脸角度偏转。 思路分析: 直接在数据库比对。 ...
  • 本文针对每一类问题给出了经过实践证明的解决方案和思路,同时说明为什么要这么做,以及在工程算法上会遇到的问题。 1 海量数据的存储、分析和处理 运维人员必须随时掌握服务器的运行状况,除常规的服务器配置...
  • 网络故障排查的思路和方法

    千次阅读 2019-12-19 18:19:21
    介绍网络处理思路和方法前,先说明网络故障处理原则: 恢复业务为首要目的。 避免处理过程中产生更大故障。 1 网络故障排错思路 网络故障发生时, 可以按照收集信息、分析现象,提出假设,验证假设,分析根因、...
  • 本文包括原理篇/思路篇/实践篇/方案篇/前端篇/总结 直播难:个人认为要想把直播从零开始做出来,绝对是牛逼中的牛逼,大牛中的大牛,因为直播中运用到的技术难点非常之多,视频/音频处理,图形处理,视频/音频压缩...
  • 使用RNN解决NLP中序列标注问题的通用优化思路

    万次阅读 多人点赞 2016-02-23 19:11:46
    /* 版权声明:可以任意转载,转载时请标明文章原始出处作者信息 .*/    author: 张俊林     (想更系统地学习深度学习知识?请参考:深度学习枕边书) ...序列标注问题应该说是自然语言处理中最...
  • 生产环境出现问题-定位问题-解决问题-原因复盘-问题定级-划分责任人(每次都希望不会是自己的问题) 无休止的测试-回归-再测试-再回归测试-已经投入了很大精力,但仍对项目质量不信心(每次都在祈祷上线顺利) 我...
  • 丢包排查思路

    千次阅读 2021-11-20 10:25:11
    在镜像流量很大的场景下,持续出现丢包,那么要分析的就是,到底是网卡处理能力的问题?还是操作系统底层Libpcap的数据采集能力有限,还是程序内部解析上存在瓶颈?我们需要从如下三个方向进行分析:
  • 产品设计思路及流程

    千次阅读 2022-02-10 09:03:43
    所谓的需求,就是找好创新点侧重点。 需求必须是明确的,客户群也是明确的。要明确需求,你必须知道需求的分类。 马斯洛需求层次理论: 1)生理需求,最基本的吃饱穿暖等。 2)安全需求,一个相对安全的生活环境...
  • 图像处理算法总结之目标检测(1)

    千次阅读 2021-12-01 20:50:48
    由于篇幅原因,本文只介绍传统的目标检测算法,在后续的文章中,我们将介绍基于深度学习的目标检测算法,基于深度学习的目标检测算法的整体思路非常优雅,敬请大家期待。 由于物体在不同的角度,不同的距...
  • 2021年数维杯数学建模分析和思路——A题

    千次阅读 多人点赞 2021-05-27 16:31:09
    问题2:您能否提出一种考虑多种因素在内的静态动态订单配送提成定价与奖惩策略,它在不显著增加订单总体配送费用与总体配送效率的基础之上,能够使得骑手总体的满意度最高。 问题3:随着全球极端气候的频发(如...
  • 性能优化的思路和步骤

    万次阅读 2017-10-18 12:53:44
    我的技术公众号,有兴趣可以...写blog写代码一样,刚开始都是不完美的,需要不断的修正重构,如果大家在阅读本blog中发现任何问题和疑问,都欢迎讨论或拍砖。 1 性能调优简介 1.1为什么要进行性能调优? ...
  • 自然语言处理面试基础

    万次阅读 2020-01-01 23:30:03
    本课程涵盖 RNN,LSTM,GRU,word2vec,CNN 这些基础,还包括多层,双向等拓展,有 Seq2seq Attention,再到最近流行的 Transformer,ELMo,BERT,层层递进掌握经典模型。 实战多: 包括 14 个项目的代码及详细的...
  • 2022mathorcupD题思路交流

    千次阅读 2022-04-14 10:02:05
    移动通信网络站址规划区域聚类问题,这道题正如题目所说,需要解决的问题包含两部分,分别是网络站址规划区域聚类问题。首先第一问: 最简单的解读就是要我们建立新基站,然后依据这些新基站画圆,其中宏基站...
  • 定义图像处理中不适定问题(ill posed problem)或称为反问题(inverse Problem)的研究从20世纪末成为国际上的热点问题,成为现代数学家、计算机视觉图像处理学者广为关注的研究领域。数学物理上的反问题的研究...
  • ...推荐搜索问题往往也可看作是序列决策的问题,引入强化学习的思想来实现长期回报最大的想法也是很自然的,事实上在工业界已有相关探索。因此后面将会写一个系列来介绍近期强化学习在搜索推...
  • 计算机应用毕业论文第八篇:日常工作问题处理中Python程序的运用摘要:Python是一门简单、实用而且有趣的百搭款语言,在Web应用开发、系统网络运维、科学与数字计算、网络编程等领域都有所建树。在计算机语言中...
  • 数据不平衡问题处理

    万次阅读 2016-05-09 00:36:12
    数据不平衡问题处理
  • 如何建立线上问题快速响应机制

    千次阅读 2019-05-18 11:33:04
      线上问题通常是指大规模影响生产服务的问题或事件,通俗点说就是"踩雷",线上问题处理的流程也可以看成是"踩雷"、“排雷”、“填雷”、“避雷”,优先级从高到底依次排序;   线上问题处理,不仅是一项技术...
  • 本文可以任意转载,转载时请标明作者出处。  张俊林 2018-11-11 (如果图片浏览有问题可以转至:知乎版本) Bert最近很火,应该是最近最火爆的AI进展,网上的评价很高,那么Be...
  • 解决这一问题的基本思路是让正负样本在训练过程中拥有相同的话语权,比如利用采样与加权等方法。为了方便起见,我们把数据集中样本较多的那一类称为“大众类”,样本较少的那一类称为“小众类”。  解决方式分为:...
  • OCR任务中,有些图片具有小角度的倾斜(±45°...这个思路来自于读研时图像分析基础课所学的内容,原理如图所示: 在实际工程中,图像的质量得不到保证,需要对图像进行灰度化、高斯模糊、直方图均衡化、去噪声等...
  • 有两个坐标点集合A、B(1<点集合数目)后期从产品(如机器零件)照相得到,选择多点处理),完成调用函数...*offset为两者偏移量,ang为两者偏移角度,nSub为两者差值.opencv刚学不到十几天,望提供资料、代码、思路
  • 2020年数学建模国赛D题题目解题思路

    万次阅读 多人点赞 2020-09-10 19:00:33
    2020年数学建模国赛D题题目: 轮廓仪是一种两坐标测量仪器(见图1),...该电信号经放大等处理,转换成数字信号储存在数据文件中(见图3)。 接触式轮廓仪测量示意图 (b) 数据文件中的数字信号 图3 接触式轮廓仪的工作
  • 自然语言处理(NLP)简介

    万次阅读 多人点赞 2020-05-30 00:00:29
    简单地说,自然语言处理就是用计算机来处理、理解以及运用人类语言(如中文、英文等),它属于人工智能的一个分支,是计算机科学与语言学的交叉学科,又常被称为计算语言学。由于自然语言是人类区别于其他动物的根本...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 164,540
精华内容 65,816
关键字:

处理问题的思路和角度