精华内容
下载资源
问答
  • 如information,其后续的一个字母有十几种,两个字母形式的后继就更多了,而显然,如果要成为一个词,其前后的搭配都应该足够的丰富和自由,这才能成为一个词,我们一般用边界熵,也就是边界稳定性衡量一个片段...

            互信息主要是过滤掉那些内部结合不紧密的片段,但只过滤掉了3%的无意义片段,而我们会发现,大量的不是词的片段是这样的形式:

    informainformat、informati,informatio这样的,属于information这个高频词一部分的片段。这些片段因为是某个词的一部分,因此,有这样一个明显的特点,就是其后续的一个字母或者几个字母非常固定。

    如informa,后续的一个字母只有l和t两种,后续的两个字母只有ti和ll两种,而作为一个独立的词,如information,其后续的一个字母有十几种,两个字母形式的后继就更多了,而显然,如果要成为一个词,其前后的搭配都应该足够的丰富和自由,这才能成为一个词,我们一般用边界熵,也就是边界稳定性来衡量一个片段搭配的分丰富程度。

    边界的长度如果取1个字母,可能误删率会很高,如果取的过长,则大部分片段的边界都可能会很丰富,因此,这里取1到6个字母,分别看下效果。还有一种方案,就是利用现有的片段直接对语料进行分词,然后统计每个片段的后继词的丰富的。这几种方案都测试下。


          首先是取1个字母的边界,如取边界熵大于0作为特征,则词的边界熵中,所有的边界熵都是大于0的,而非词的边界熵中,有大概7%的边界熵是等于0的,其它的是大于0的。可以看到,边界熵对分辨词和非词还是非常有效的,


              当然,我们还可以取一个更大的边界熵阈值,过滤掉更多的非词片段,如取边界熵大于1作为特征,则词的边界熵中,只有2%左右是小于1的,而非词中有37%的都是小于1的,显然如果取边界熵的阈值为1作为过滤条件,显然比取0要好一些。但如果阈值取的过大,显然会造成误删除过多,而如果过小的话,过滤掉的词又太少,因此我们可以按照特性选取的方法,如信息增益来衡量特征的优劣。

                信息增益应用到我们的场景中,类别C包含两个类别,记C1为是词的类别,C2是非词的类别,t为阈值特征,即为大于一个边界熵阈值,而!t表示小于边界熵阈值,这里取阈值为1作为例子计算,其公式可以表示为:

    IG = H(C) - H(C|T),其中:H(C)就是分类系统的概率

    也就是H(C) = -P(C1)logP(C1)+-P(C1)logP(C2), P(C1)就是C1出现的概率,也就是词的数目,除以所有片段的数目

    这里H(C) = -0.0222log(0.0222)+ 0.9778log( 0.9778)=0.1537

      H(C|T) = H(C|t) + H(C|!t)

    其中H(C|t) = P(t)[  H(C1|t)+H(C2|t) ]=P(t)[  -P(C1|t)logP(C1|t) + -P(C2|t)logP(C2|t)  ]

    而H(C|!t) = P(!t)[  H(C1|!t)+H(C2|!t) ]=P(!t)[  -P(C1|!t)logP(C1|!t) + -P(C2|t)logP(C2|!t)  ]

    其中,P(t)就是大于阈值的所有的片段的概率,就是大于阈值的片段数目除以全部的片段数据,P(!t)就是小于阈值的片段数目除以全部的片段数目:

    P(t) = 0.6367,P(!t) = 0.3633

    而P(C1|t)就是t中属于类别C1的概率,也就是大于阈值的片段中是词的概率,P(C1|!t)的含义类似

    P(C1|t) = 0.0341,P(C2|t) = 0.9659

    P(C1|!t) = 0.0013,P(C2|!t) = 0.9987

    则H(C|t) =0.6367*0.2145 = 0.1366

    H(C|!t) =0.3633*0.0144 =  0.0052

    可以得到,H(C|T) = 0.1366 +  0.0052 = 0.1418

    而信息增益为:H(C)-H(C|T) = 0.1537-0.1418 = 0.0119


    同样的,我们如果取阈值为0,则信息增益为0.0022(注意,这里假设任何情况下,词或者非词片段至少出现1次,否则可能出现log0的情况),显然不如取1效果好,这里取阈值从0到4,分别看信息增益,然后取一个效果最好的,也就是信息增益的最大值时对应的阈值:

    根据上图,可以确定去阈值为2.6左右时,信息增益最大,这时,词的边界熵中,有18%左右是小于2.6的,而非词中有69%的都是小于2.6的,相当于过滤掉了将近70%的非词片段,而词的片段有18%是误删除的,这个比例是否合适,需要由我们的应用效果,也就是分词的准确率和覆盖率来确定,这就要不断的做实验,看效果。

    在中文处理中,一般取边界宽度为一个词即可,但英文中字母非常少,因此边界到底取多长其实相对比较难确定,这就需要不断的实验,这也是非监督方法的一个主要困难。

    此外,我们还可以先用初始词典对语料进行分词,然后边界宽度设置为一个词,这样也是可以的。

    在我们的测试中,如果取边界宽度为1,阈值为1.3,用30万的候选词进行过滤,这时候的效果是最好的,其准确率和覆盖率都达到了43%左右。我们的基线大概是40%左右,虽然提高的不是很多,但是已经去掉了一多半以上的不是词的片段,而是词的片段只删掉了不到10%。这就为后续的处理提供了很多的便利。


    展开全文
  • 上一篇中我们说到了Android应用的瘦身优化——《深入探索Android应用瘦身优化》,今天一起来学习一下应用的稳定性优化,废话不多说了,我们直接进入主题!

    目录

    写在前面

    一、如何提升App的稳定性

    1.1、稳定性维度

    1.2、稳定性优化概述

    二、如何有效降低应用崩溃率

    2.1、Crash相关指标

    2.2、Crash关键问题

    2.3、单个Crash处理方案

    2.4、Crash率治理方案

    2.5、如何选择合适的崩溃服务

     三、移动端业务高可用方案

    四、移动端容灾方案

    4.1、移动端容灾必要性

    4.2、移动端容灾最佳实践

    五、稳定性长效治理


    写在前面

    上一篇中我们说到了Android应用的瘦身优化——《深入探索Android应用瘦身优化》,今天一起来学习一下应用的稳定性优化,废话不多说了,我们直接进入主题!

    一、如何提升App的稳定性

    一般性的App能接触到稳定性的需求其实并不多,只有大型的处于稳定运营期的App才会重视App的稳定性,稳定性实际上是一个大问题,一个稳定的产品才能够保证用户的留存率,所以稳定性是质量体系中最基本也是最关键的一环:

    • 稳定性是大问题,Crash是P0优先级:对于用户来说很难容忍你的应用发生崩溃
    • 稳定性可优化的面很广:不仅仅是指崩溃,像卡顿、耗电等也属于稳定性优化的范畴,对于移动端高可用这个标准来说,性能优化只是高可用的一部分,还有一部分就是应用业务流程功能上的可用

    1.1、稳定性维度

    • Crash维度:一般会将Crash单独作为一项重要指标进行突破,最常见的统计指标就是Crash率,后面会说到
    • 性能维度:启动速度、内存、卡顿、流量、电量等等,在解决应用的Crash之后,就应该着手保障性能体系的稳定
    • 业务高可用维度:业务层面的高可用是相当关键的一步,需要使用多种手段去保障App业务的主流程及核心路径的可用性

    1.2、稳定性优化概述

    如果App到了线上才发现异常,其实已经造成了损失,所以稳定性优化重点在于预防

    • 重在预防、监控必不可少:从开发到测试到发布上线运维这些各个阶段都需要预防异常的发生,或者说要将发生异常造成的损失降到最低,用最小的代价暴露最多的问题,同时监控也是必不可少的一步,需要拥有一定的监控手段来更加灵敏的发现问题
    • 思考更深一层、重视隐含信息:比如你发现了一个崩溃,但是你不能简单的只看这一个崩溃,要考虑这个崩溃是不是在其他地方也有同样或者类似的,如果有就考虑是否统一处理,今后该如何预防,总结经验
    • 长效保持需要科学流程:在项目的每一个阶段建立完善的相关规范,保证长效的优化效果

    二、如何有效降低应用崩溃率

    2.1、Crash相关指标

    ①、UV、PV Crash率

    • UV Crash率:等于Crash UV/DAU:主要针对于用户使用量的统计,它统计一段时间内所有用户中发生过崩溃的用户占比,和UV强相关,UV是指Unique Visitor一天内访问网站的人数(是以cookie为依据),一天内同一访客的多次访问只计算为1,一台电脑不同的浏览器的cookie值不同。
    • PV Crash率:针对用户使用频率的统计,统计一段时间内所有用户启动次数中发生崩溃的占比,和PV强相关,PV是指PageView也就是页面点击量,每次刷新就算一次浏览,多次打开同一页面会累加。
    • UV Crash方便评估用户影响范围,PV Crash方便评估相关Crash的影响严重程度
    • 注意:沿用同一种衡量方式:不管你是使用UVCrash还是PVCrash作为主要指标,你应该一直使用它,因为和Crash率相关的会有一些经验值,这些经验值需要对应一个衡量指标

    ②、Java、Native Crash率

    • Java Crash:在Java代码中,出现了未捕获的异常,导致程序异常退出
    • Native Crash:一般都是因为在Native代码中访问非法地址,也可能是地址对齐出现了问题,或者发生了程序主动abort,这些都会产生相应的signal信号,导致程序异常退出。目前Native崩溃中最成熟的方案是BreakPad

    ③、启动、重点流程Crash率

    • 启动Crash率:在启动阶段用户还没有完全打开就发生了崩溃的占比,只要是用户打开App10s之内发生的崩溃都被视为启动Crash,它是Crash分类中最严重的一类,我们需要重点关注这个指标,而且降低的越低越好,并且我们应该结合客户端的容灾策略进行自主修复

    ④、增量、存量Crash率

    • 增量Crash:指新增Crash,它是新版本Crash率变动的原因,如果没有新增的Crash,那么新版本的Crash率应该是和老版本Crash率保持一致,所以增量Crash是新版本中需要重点解决的问题
    • 存量Crash:指老版本中已经存在的Crash,这些Crash一般都是难以解决或者是需要在特定场景下才会出现的难以复现的问题,这类问题需要长期投入精力持续解决
    • 优先解决增量、持续跟进存量

    ⑤、Crash率评价指标

    • 务必在千分之二以下:Java和Native的崩溃率加起来需要在千分之二以下才能算是合格的
    • Crash率处于万分位视为优秀的标准

    2.2、Crash关键问题

    ①、尽可能还原Crash现场

    一旦发生崩溃,我们需要尽可能保留崩溃现场信息,这样有利于还原崩溃发生时的各种场景信息,从而推断出可能导致崩溃的原因,对于采集环节可以参考以下采集点:

    • 采集堆栈、用户设备、OS版本、发生崩溃的进程、线程名、崩溃前后的Logcat
    • 前后台、使用时长、App版本、小版本、渠道
    • CPU架构、内存信息、线程数、资源包信息、行为日志

    上面是一张Bugly后台的截图,对于成熟的性能监控平台不仅有Crash的单独信息,同时会对各种Crash进行聚合以及报警。

    ②、APM后台聚合展示

    • Crash现场信息:包括Crash具体堆栈信息及其它额外信息
    • Crash Top机型、OS版本、分布版本、发生地域:有了这些Top Crash信息之后就能够知道哪些Crash的影响范围比较大需要重点关注
    • Crash起始版本、上报趋势、是否新增、持续版本、发生量级等等:可以从多个视角判断Crash发生的可能原因以及决定是否需要修复,在哪些版本上进行修复

    ③、Crash相关的整体架构

    ④、非技术相关的关键问题

    建立规范的流程保证开发人员能够及时处理线上发生的问题:

    • 专项小组轮值:成立专门小组来跟踪每个版本周期之内线上产生的Crash,保证一定有人跟进处理
    • 自动分配匹配:可以自定义某些业务模块名称,自动分配给相应人员处理
    • 处理流程全纪录:记录相应人员处理Crash的每一步,后期出现问题追究相关责任人也是有据可查的

    2.3、单个Crash处理方案

    • 根据堆栈及现场信息找答案:一般来说堆栈信息可以帮助我们解决90%的问题
    • 找共性比如机型、OS、实验开关、资源包等:有些Crash信息通过堆栈找不到有用的帮助,不能直接解决,这种情况下可以通过Crash发生时的各种现场信息作辅助判断,分析这些Crash用户拥有哪些共性
    • 线下复现、远程调试:有了共性之后尝试在线下进行复现,或者尝试能否进行远程调试

    2.4、Crash率治理方案

    • 解决线上常规Crash:抽出一定时间来专门解决所有常规的Crash,这些Crash一般相对来说比较容易解决
    • 系统级Crash尝试Hook绕过:当然Android系统版本一直在不断的升级,随着新系统的覆盖率越来越高,老版本的系统Bug可能会逐渐减少
    • 疑难Crash重点突破、更换方案:做到长期跟踪,团队合作重点突破,实在不行可以考虑更换实现方案

    通过以上几点应该可以解决大部分的存量Crash,同时再控制好新增Crash,这样一来整体的Crash率一般都能够得到有效降低。

    这一部分的内容有点杂而多,一般也是需要多端配合,所以不太好做具体演示,大家可以在网上多查找相关资料进行巩固学习。

    2.5、如何选择合适的崩溃服务

    1. 腾讯Bugly: 除了有crash数据还有运营数据
    2. UC 啄木鸟:可以捕获Java、Native异常,被系统强杀的异常,ANR,Low Memory Killer、killProcess。技术深度以及捕获能力强
    3. 网易云捕:继承便捷,访问快,捕获以及上报速度及时,支持实时报警,提供多种报警选项,可以自定义参数。
    4. Google的Firebase
    5. crashlytics:服务器在国外,访问速度慢,会丢掉数据
    6. 友盟:crash之后会在再次启动的时候上报数据,所以不能立即获得这部分信息

     三、移动端业务高可用方案

    移动端高可用方案不仅仅是指性能方面的高可用,业务方面的高可用也是尤为重要的,如果业务都走不通,试问你性能做的再好又有何用呢?

    • 高可用:性能+业务 
    • 业务高可用侧重于用户功能完整可用
    • 业务高可用影响公司实际收入:比如支付流程不通 

    对于业务是否可用不像Crash一样,如果发生Crash我们可以收到系统的回调,业务不可用实际上我们是无从知道的,所以针对建设移动端业务高可用的方案总结以下几点:

    ①、数据采集

    • 梳理项目主流程、核心路径、关键节点:一般需要对项目主流程和核心路径做埋点监控,比如用户下单需要从列表页到详情页再到下单页,这就是一个核心路径,我们可以监控具体每个页面的到达率和下单成功率
    • AOP自动采集、统一上报:数据采集的时候可以采用AOP的方式,减少接入成本,上报的时候可以采取统一的上报减少流量和电量消耗,上传到后台之后再做详细的分析,得出所有业务流程的转化率,以及相应界面的异常率

    ②、报警策略

    • 阈值报警:比如某个业务失败的次数超过了阈值就报警通知
    • 趋势报警:对比前一天的异常情况,如果增加的趋势超过了一定的比例即便是未达阈值也要触发报警
    • 特定指标报警、直接上报:比如支付SDK调用失败,这种错误无需跟着统一的数据上报,出现立即上报

    ③、异常监控

    • Catch代码块:实际开发中我们为了避免程序崩溃,经常会写一些try{}catch(){}来捕获相关异常,但是这样操作完成之后,程序确实不崩溃了,相应的功能也是无法使用的,所以这些被Catch住的异常也要上报,有利于分析功能不可用的原因
    • 异常逻辑:比如我们需要对结果为true的调用方法进行处理,结果为false时不执行任务,但是我们也需要上报异常,统计一下出现这种情况的用户的占比情况,以便针对性的优化

    这里简单的举个栗子,表明意思:

            try {
                //业务处理
                LogUtils.i("...");
            }catch (Exception e){
                //如果未加上统计,就无法知道具体是什么原因导致的功能不可用
                ExceptionMonitor.monitor(Log.getStackTraceString(e));
            }
    
            boolean flag = true;
            if (flag){
                //正常,继续执行相关任务
            }else {
                //异常,不执行任务,这种情况产生的异常也应该进行上报
                ExceptionMonitor.monitor("自定义业务失败标识");
            }        
    

    ④、单点追查

    • 需要针对性分析的特定问题:这些问题相对小众,很可能是和特定用户的操作习惯、账户体系相关,所以要尽可能获取多的数据重点分析
    • 全量日志回捞,专项分析:很多日志信息默认都是只记录不上传,比如用户全部的行为日志,这些日志只有在需要的时候才有用,平时没必要上传,没啥用还浪费流量,如果需要排查特定用户的详细信息,也可以通过服务端下发指令客户端接收指令后上传

    ⑤、兜底策略

    当你通过监控了解到业务不正常之后,请问该如何修复?这里就要用到兜底策略了,就是到了最后一步各种措施都做了,用户还是出现了异常,这种情况仍然还是要有相关联的配置手段来达到高可用。对于业务上的异常除了热修复的手段之外,还可以通过建立配置中心,将功能开关关闭。

    • 配置中心,功能开关:实际项目中很多数据都是通过服务端动态下发配置的,将这些功能集合起来的处理平台就是配置中心。举个栗子:比如新版本上线了一个新功能,加了一个入口,上线之后发现功能不稳定,此时就可以通过服务端配置的方式将此功能开关关闭,这样即使用户无法使用新功能,但是至少不会发现业务的异常
    • 跳转分发中心:熟悉组件化开发的朋友都知道做组件化module的拆分必不可少的就是要有一个路由,它的作用就是跳转分发中心,所有的跳转都是通过路由来做,如果匹配到需要跳转到有Bug的功能界面时可以统一跳转到一个异常处理的页面

    四、移动端容灾方案

    4.1、移动端容灾必要性

    说到容灾,首先来看一下需要防范的灾是什么?主要分为两部分:性能异常和业务异常,只要是对用户的实际体验产生了很大的影响,都是需要防范的App线上灾害。

    • 灾:性能、业务异常

    传统的流程是如何处理线上出现的紧急问题的呢?传统的处理流程首先需要用户反馈出现的不正常情况,接着开发人员进行紧急的BUG修复,然后重新打包上传渠道进行更新,可见传统的流程比较繁琐,灵敏度较低,如果日活量较高,随着Bug在线上存活的时间延长对用户基数的影响是巨大的,势必是无法接受的

    • 传统流程:用户反馈、重新打包、渠道更新,不可接受

    4.2、移动端容灾最佳实践

    ①、功能开关

    • 配置中心,服务端下发配置控制:首先对任何新上线的功能加上功能开关,可以通过配置中心的方式下发开关决定是否显示新功能的入口,出现异常情况可以随时关闭入口,这样可以保证上线的新功能处于可控状态
    • 针对场景,功能新加或代码改动:一是新增了功能,二是出现了代码改动,比如重构代码,最好保留之前的老方案,在新方案上线之后如果有问题,可以切回之前的老方案

    这里简单的做个演示:

    public class ConfigManager {
    
        public static boolean mOpenClick = true; //默认值为true
    
    }
    
    mAdapter.setOnItemClickListener((view, position) -> {
                //控制点击事件是否开启
                if (ConfigManager.mOpenClick){ //mOpenClick的值从接口获取,由服务端控制
                    //处理具体业务
                }
            });

    ②、统跳中心

    组件化之后的项目的页面跳转都是通过路由来做的,如果发现线上产生了异常,可以在路由跳转这一步拦截有Bug的跳转,重定向到备用方案,或者统一的错误处理中界面,更多的情况是为了对线上用户产生的影响降到最低,如果有Bug不能进行热修复,也没有合适的开关可用,会做一个临时的H5页面,让用户点击之后跳转到临时的H5页面,这样用户还是可以操作,只是在体验上稍微差一点,总归来说比不能用强的多

    • 界面切换通过路由,路由决定是否重定向
    • Native Bug不能热修则跳转到临时H5

    ③、动态化修复

    目前为止,国内市场安卓的热修复方案已经比较成熟了,对于大型项目来说,一般都会支持热修复的能力,热修复技术就是用户不需要重新安装一个Apk,就可以实现比原有Apk有较大更新的能力,比如微信的Tinker和美团的Robust都是非常好的热修复实现方案。需要注意的是,热修复也只是一个功能,对于热修复也需要加上各种完善的统计,需要知道热修方案是否真正有效果,没有用造成更大的损失

    • 热修复能力,可监控、灰度、回滚、清除
    • 推拉结合、多场景调用保证到达率
    • Weex、RN增量更新

    ④、安全模式

    安全模式侧重于移动端发生严重Crash时的自动恢复,做的好的安全模式往往会有几级不同的策略,比如App多次启动失败,那就重置整个App到安装的状态,避免因为一些脏数据导致的App持续闪退,同时如果有Bug并且非常严重到了最严重的等级,可以采用阻塞性热修来解决,即:必须等热修成功之后才可进入主页面。需要注意的是,安全模式不仅仅可以针对App Crash,也可以针对一些组件,比如网络请求多次失败后也可以进入安全模式,暂时拒绝用户的网络请求,避免给服务端造成的额外压力

    • 根据Crash信息自动恢复,多次启动失败重置App
    • 严重Bug可阻塞性热修复
    • 异常熔断:多次请求失败则主动拒绝

    这里推荐一篇文章:《安全模式:天猫App启动保护实践》

    容灾方案总结:

    功能开关---》统跳中心---》动态修复---》安全模式

    这几种方式是由简单到复杂的递进,为了保障线上的稳定性,最好在应用中多加入几个稳定性保障方案。

    五、稳定性长效治理

    对于稳定性优化来说是一个细活,需要打持久战,不能一个版本优化了,后面又恶化了,因此需要在项目开发的整个周期内的不同阶段都加上相应的方案。

    ①、开发阶段

    在开发阶段组内每个开发人员的编码实力都是不一样的,因此需要统一编码规范,然后结合一些手段增强人员的编码功底,尽可能的将问题消灭在编码阶段,尽可能的写出高质量的代码,同时要结合开发阶段的技术评审,以及每天的互相CodeReview机制,坚持几个月编码水平肯定会有明显的提升,开发阶段明显的问题应该就不会再有了,而且代码风格结构也会大体一致。同时开发阶段还需要做的事情就是架构优化,项目的架构应该根据项目的不同发展阶段来不断优化,这里说两点,第一能力收敛比如界面切换的能力用路由来实现,对网络请求要统一网络库统一使用方式,这样可以避免不正当的使用带来的Bug,第二统一容错,比如对于网络请求来说可以在网络请求回来的时候加上预先校验,判断回来的数据是否合法,如果不合法就不需要再把数据转给上层业务了

    • 统一编码规范、增强编码功底、技术评审、CodeReview机制
    • 架构优化:能力收敛、统一容错

    ②、测试阶段

    • 功能测试、自动化测试、回归测试、覆盖安装
    • 特殊场景、机型等边界测试
    • 云测平台:辅助测试,满足对特殊机型的测试需求

    ③、合码阶段

    开发时肯定是在自己的分支进行开发,测试通过之后才会往主干分支合入,合入之前首先需要进行代码的编译检查和静态扫描发现可能存在的问题,经过校验之后也不能直接合入,应该将自己的分支首先合入到一个和主干分支一样的分支中进行预编译,编译通过之后最好加上主流程的回归测试

    • 编译检测,静态扫描
    • 预编译流程、主流程自动回归

    ④、发布阶段

    到了发布阶段一般来说App都是经过了开发自测、QA测试、内部测试等测试环节,相对来说比较稳定了,但是需要注意的是,很多问题你不可能全部测出来,所以必须谨慎对待

    • 多轮灰度:灰度的量级要由小变多,争取以最小的代价暴露最多的问题
    • 分场景、维度全面覆盖

    ⑤、运维阶段

    任何一个小问题在海量用户面前都会影响巨大,因此这个阶段必须要依靠APM的灵敏监控

    • APM灵敏监控
    • 回滚、降级策略
    • 热修复、容灾方案 

    好了,关于App稳定性优化的相关内容就说到这里了,下期再见!

    祝:工作顺利!

    展开全文
  • Part 10 App稳定性优化

    2019-04-09 10:50:49
    一 如何提升App的稳定性 1、正确认识 稳定性是大问题,Crash是P0优先级的 稳定性可优化面很广(Crash、卡顿、耗电等) 2、稳定性纬度 Crash纬度 性能纬度(启动速度、卡顿、电量、流量、内存等) 业务的高可用纬度 3、...

    Part 10

    一 如何提升App的稳定性

    1、正确认识

    稳定性是大问题,Crash是P0优先级的
    稳定性可优化面很广(Crash、卡顿、耗电等)

    2、稳定性纬度

    Crash纬度
    性能纬度(启动速度、卡顿、电量、流量、内存等)
    业务的高可用纬度

    3、稳定性优化概览

    重在预防、监控必不可少
    思考更深一层、重视隐含信息
    长效保持需要科学流程

    二 高Crash率的破解之道

    1、Crash相关指标

    UV、PV Crash率

    PV访问量(Page View),即页面访问量,每打开一次页面PV计数+1,刷新页面也是。
    UV访问数(Unique Visitor)指独立访客访问数,一台电脑终端为一个访客。
    UV Crash率 = Crash UV(发生崩溃的用户)/DAU(日活跃用户数量)
    UV方便评估用户影响范围
    PV方便评估Crash的影响程度
    注意:沿用一种衡量方式作为评定指标

    Java、Native Crash率

    Java Crash开发中最常见问题如各种的EXCEPTION
    Native Crash相对来讲比较难以分析的类型

    启动、重点流程Crash率

    影响最严重的Crash
    结合客户端容灾

    增量、存量Crash率

    增量->新出现的Crash->新版本的重点
    存量->老版本就有Crash->继续啃的硬骨头
    处理策略: 优先解决增量、持续跟进存量

    crash率评价

    Java、Native的Crash务必在千分之二以下
    Crash率万分位优秀

    2、Crash关键问题

    尽可能还原Crash现场

    堆栈、设备、OS本版、进程、线程名、logcat
    前后台、使用时长、App版本、小版本、升级渠道
    CPU架构、内存信息、线程数、资源包信息、行为日志

    APM后台聚合展示

    Crash线程信息
    Crash Top机型、os版本、分布版本、区域
    Crash起始版本、上报趋势、是否新增、持续、量级

    在这里插入图片描述

    3、Crash治理方案

    解决线上常规Crash
    系统级的Crash尝试Hook绕过
    疑难Crash重点突破、更换方案

    三 移动端业务高可用方案

    1、业务高可用重要性

    高可用:性能+业务
    业务高可用侧重于用户功能完整可用
    业务高可用真实的影响收入

    2、业务高可用方案建设

    数据采集

    梳理项目主流程、核心路径、关键节点
    Aop自动采集、统一上报

    报警策略

    阈值报警(某个点击事件不可相应超过一定次数)
    趋势报警(昨天异常和今日的对比)
    特定指标报警、直接上报

    异常监控

    Catch代码块(catch导致的功能不可用)
    异常逻辑(如:返回false导致的功能不可用的统计)

            // 以下代码是为了演示业务不正常场景下的监控
            try {
                // 一些业务处理
                Log.i("", "");
            } catch (Exception e) {
                ExceptionMonitor.monitor(Log.getStackTraceString(e));
            }
            
            // 异常逻辑场景下的监控
            boolean flag = true;
            if (flag) {
                // 正常,继续执行流程
            } else {
                ExceptionMonitor.monitor("");
            }
            
        //异常控制类
        public class ExceptionMonitor {
            public static void monitor(String message){
                // 数据缓存及后续上报逻辑
            }
        }    
    

    单点追查

    需要针对性分析的特定问题
    全量日志回捞,专项分析

    兜底策略

    热修复
    配置中心,功能开关(服务端动态控制业务功能)
    跳转分发中心(模块化开发的路由,有问题的界面不进行跳转或跳转至统一提示界面)

    四 移动端容灾方案

    1、移动端容灾方案必要性

    灾:性能、业务异常
    传统流程:用户反馈、重新打包、渠道更新

    2、容灾方案建设

    功能开关

    配置中心,服务端下发配置控制
    针对场景:功能新加或代码改动

    示例代码

    //配置管理类
    public class ConfigManager {
    
        public static boolean sOpenClick = true;
    
    }
        
    //在添加或者修改的代码中添加判断
    if(ConfigManager.sOpenClick){
        //新逻辑
    }else{
        //老逻辑
    }
    
    //通过服务端接口的返回值修改sOpenClick的状态
    
    

    统跳中心

    界面切换通过路由,路由决定是否重定向
    eg:Native Bug不能热修复则跳转到临时的H5界面中

    动态化修复

    热修复能力、可监控、灰度、回滚、清除
    推拉结合、多场景调用保证到达率
    Weex、RN增量更新

    安全模式

    根据Crash信息自动恢复,多次启动失败重置App
    严重Bug可阻塞性热修复(只有热修复成功才可进入app主界面)
    异常熔断:多次请求失败则主动拒绝

    示例代码

        1.通过UncaughtExceptionHandler记录崩溃
        
        2.在Application中
        private int mCrashTimes;//崩溃次数
        @Override
        protected void attachBaseContext(Context base) {
            super.attachBaseContext(base);
    
            if(mCrashTimes > 3){
                // 删除文件,恢复到重新安装的状态
            }
    
            if(mCrashTimes > 5){
                // 清除热修信息
            }
    
        }
    

    五 稳定性长效治理

    1、全流程Crash长效治理

    开发阶段

    统一编码规范、增强编码功底、技术评审、CodeReview机制(用3个月左右的时间统一之后一般可达到目的)
    架构优化:能力收敛、统一容错

    测试环节

    功能测试、自动化测试、回归测试、覆盖安装
    特殊场景、机型等边界测试
    云测平台(提供多种机型)

    合码阶段

    编译检查、静态扫描
    预编译流程、主流程自动回归

    发布阶段

    多轮灰度(又少变多)
    分布场景、纬度全面覆盖

    运维阶段

    灵敏监控
    回滚、降级策略
    热修、容灾方案

    展开全文
  • 对于大型应用后台系统来说,稳定性至关重要。目前越来越多的大型应用系统采用微服务架构,更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。针对我们业务后台系统...

    对于大型应用后台系统来说,稳定性至关重要。目前越来越多的大型应用系统采用微服务架构,更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。


    针对我们业务后台系统建设,任何大型业务后台系统绝对不是一蹴而就。它是伴随着业务不同阶段,不断进行演进的过程。如果经历过从 0 到 1 建设一个业务后台系统的同学,都会有类似的体会。


    01

    启动阶段


    启动阶段,业务模型相对简单,用户量少,这时候我们可以将所有的系统模块耦合在一个工程里面,进行单机部署。这时候可能仅仅需要将业务系统与数据库进行隔离。


    02

    探索阶段


    探索阶段,业务模型不断演进,用户量增加,单机服务能力瓶颈凸显。这时候就需要由单机服务部署向集群服务部署来优化,利用负载均衡将请求合理分配,减少单机服务压力。另外一个方面,数据量不断的增加,也需要考虑针对数据来进行水平的扩展(主从部署,读写分离)。


    在这一阶段,我们仅仅是做了集群扩展,但所有的业务代码都在同一个工程维护,所有的数据信息都在同一个数据库中存储。随着团队的扩充与业务交互不断复杂化,在工程维护上存在很大的风险,工程研发效率受到制约,业务代码之间的耦合也难以清晰,系统可靠性存在很大风险,一个 bug 可能会造成整个应用的崩溃不可用。


    03

    发展阶段


    如果我们比较幸运,业务持续快速发展,对于业务角色模型理解越来越清晰,业务角色模型之间的交互越来越确定。这时候就需要我们基于对业务充分的理解前提下进行垂直拆分。不同的业务模型会部署到不同的系统工程中,工程之间通过接口来进行交互。


    这样工程内业务高度集中,工程间通过接口服务来进行解耦。这时候不管是系统维护,还是业务模块维护,都将大大的提高效率。数据部分同样垂直拆分,不同业务数据拆分到不同的数据库,从而提高单机数据库的能力。


    拿电商系统的结构来说,如下图所示:

    640?wx_fmt=png

    基于业务模型分为几个大的系统服务,系统服务之间通过内部 RPC 接口来进行交互。


    04

    成熟阶段


    上面是基于大的业务模型进行划分,随着业务复杂度越来越高,我们必将对大业务模型,基于功能或者业务边界进行更细粒度的拆分。比如说,我们可以将产品中心划分为:基础信息中心,库存管理中心,SKU 中心等。


    这时候就涉及到微服务的拆分与治理工作。


    微服务的拆分原则我们应该注意:业务功能单一;服务间业务边界清晰;拆分粒度合理;分层划分合理。


    从研发的角度来说,微服务带来的好处:研发效率提升;代码质量更优;能够独立部署;单模块复杂度降低。上面提到的产品中心我们可以拆分很多小的服务来提供,如下图所示:

    640?wx_fmt=png

    细粒度的拆分,也会带来一定的挑战:

    • 微服务划分单元越细,整体服务维护非常复杂;

    • 微服务通过 RPC 接口交互,整个链路可能会不清晰;

    • 单服务的修改或者优化会受到其他模块的牵制。


    当然这些挑战都是我们需要思考与解决的问题,并不能抹杀微服务的优点。在这篇 Chat 文章里,我系统的梳理了一下大型网站后台稳定性的技术策略,堪称“行动指南”!!


    扫描下方二维码查看完整全文

    进入读者圈与作者深入交流

    640?wx_fmt=jpeg


    点击阅读原文,订阅本场 Chat ,查看完整原文!

    展开全文
  • 大型网站后台稳定性技术策略

    千次阅读 2019-07-01 14:21:21
     对于大型应用后台系统来说,稳定性至关重要。目前越来越多的大型应用系统采用微服务架构,更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。  基础知识  在介绍稳定性技术策略主题之前,...
  • 系统稳定性治理最佳实践

    千次阅读 2020-02-11 13:19:40
    系统稳定性治理最佳实践 稳定压倒一切,没有稳定就没有生成。国家是如此,业务系统也是如此。老子说,“治大国若烹小鲜”,治理系统也是要做到同样,要掌握火候,精选食材,用料恰当,辅以煎炒烹炸煮,则方能出...
  • 深入探索Android稳定性优化

    万次阅读 多人点赞 2020-03-12 12:12:31
    2、稳定性优化注意事项 我们在做应用的稳定性优化的时候,需要注意三个要点,如下所示: 1、重在预防、监控必不可少 对于稳定性来说,如果App已经到了线上才发现异常,那其实已经造成了损失,所以,对于稳定性的...
  • 2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性...
  • 智力评分的稳定性:对学习障碍学生 3 年重新评估的影响 118 Michael J. Fimian FIMIAN, MJ, & BLANTON, LP (1986)。 与特殊教育教师 FIMIAN、MJ 和 BLANTON,LP(1987 年,印刷中)中的压力和倦怠相关的变量。 ...
  • 针对位场数据处理中边界定位精度和识别能力的问题,提出一种新的边界检测方法――均方差比...模型试验对比分析结果表明,NVD-MSER方法具有计算稳定性强、反映的边界位置连续性好、与实际模型边界对比偏差小的优点,这说
  • 提高GAN训练稳定性的9大tricks

    千次阅读 2019-02-25 15:17:25
    一般来说,使用梯度惩罚机制可以帮助避免这种状态的产生,极大增强 GAN 的稳定性,尽可能减少 mode collapse 问题的产生。   4. Spectral Normalization(谱归一化)   Spectral normalization 是用在...
  • 用时域有限差分法计算目标的雷达散射截面时,一般用连接边界来引入平面入射波,理想情况下,当总场...研究表明时间步长、入射角度都能影响电磁泄漏大小,为使电磁泄漏较小,时间步长应接近于稳定性要求的最小步长,入射
  • anchor-based的边界框回归损失函数

    千次阅读 2021-03-02 14:48:48
    边界框回归(regression)损失函数汇总,L1、L2、Smooth L1、IoU、GIoU、DIoU、CIoU、EIoU。
  • 项目管理和软件开发的边界

    千次阅读 2017-10-21 16:21:21
    程序员的人生就是和一个个的软件项目打交道的人生。 不能管理好项目过程的程序员不是好的开发人员。...所以如何区分好项目管理和软件开发的边界,统筹好二者才是一个好的互联网项目管理和软件开发过程。
  • BGP边界网关协议 - 从零开始学习

    千次阅读 2021-01-13 11:00:45
    BGP边界网关协议概述AS的概念BGP使用的协议和端口号BGP的路由器号(Router-ID)BGP协议路由的特点BGP的分类EBGPIBGPBGP的五种报文BGP的六种状态机BGP的九个原则建立邻居的注意点 概述 它是一种实现AS之间的路由可达并...
  • 作者提出了一个衡量生成样本多样的超参数 γ : 生成样本损失的期望与真实样本损失的期望值之比。在作者的模型中,判别器有两个目标:对真实图像自编码,并且将生成图像与真实图像区分开。这个超参数能够平衡这两...
  • 编程即设计,代码即架构。... 但架构并不研究如何实现具体服务,—— 它研究的是如何妥善安置那些实现服务的构件,管理依赖、边界和变化。 如何将不变从变化中分离出来,沉淀为稳定的组件 ?如何管...
  • ”这是至顶科技创始人玮哥引用《人类简史》的一段话,在他看来,区块链确实具备跨越边界的能力,但是我们不用刻意去突破我们所能看到的一切边界,也许如何认知、设定这个边界,才是通证经济要考虑的最主要问题。...
  • 稳定性能 ​ 。负载测试:通过负载测试来确定在各种工作负载下,系统各项性能指标的变化情况 ​ 。压力测试:通过确定一个系统的瓶颈或者刚好不能接受的性能点,来获得系统能够提供提供的最大服务级别。 15、随机...
  • 但这不是个稳定结构,所以还会有 4 进 3,3 进 2,比如百度外卖先出局了。除非像微信那样全国网络效应超强的业务,否则在很多领域是不会出现一家独大的。总有消费者喜欢不一样的品牌,可口可乐或是百事可乐,耐克...
  • 我们有很多方法来衡量特征的重要,这里呢,将会介绍一种方法:排列重要。这种方法和其他方法比起来,优势有: ❶ 计算速度快 ❷ 广泛使用和理解 ❸ 我们希望特征重要与属性具有一致 工作原理...
  • 【软件设计】软件设计特性

    千次阅读 2015-10-08 14:50:13
    它是衡量设备在投入使用后实际使用的效能,是设备或系统的可靠、可维护和维护支持的综合特性。2、安全 为防止把计算机内的机密文件泄露给无关的用户,必须采取某种安全保密措施,这些措施的有效程序如何
  • DIoU要比GIou更加符合目标框回归的机制,将目标与anchor之间的距离,重叠率以及尺度都考虑进去,使得目标框回归变得更加稳定,不会像IoU和GIoU一样出现训练过程中发散等问题。 https://arxiv.org/pdf/1911.08287.pdf...
  • 数据与数据库完整测试是指测试关系型数据库完整原则以及数据合理测试。 数据库完整原即: 主码完整:主码不能为空; 外码完整:外码必须等于对应的主码或者为空。 数据合理指数据在数据库中的...
  • 关于相似以及文档特征、词特征有太多种说法。弄得好乱,而且没有一个清晰逻辑与归类,包括一些经典书籍里面也分得概念模糊,所以擅自分一分。 ————————————————————————————...
  • SRE实战手册-基础篇

    2021-01-09 15:40:16
    稳定性保障体系 系统可用性 描述系统稳定性 时间维度 请求维度 选择合适的 SLI(指标) 设定系统稳定性 SLO(目标) 错误预算 稳定性保障体系 稳定性保障规划图: MTBF,...
  • 机器学习模型可解释的详尽介绍

    千次阅读 多人点赞 2019-11-26 12:22:00
    机器之心平台来源:腾讯技术工程模型可解释方面的研究,在近两年的科研会议上成为关注热点,因为大家不仅仅满足于模型的效果,更对模型效果的原因产生更多的思考,这样的思考有助于模型和特征的优化,更能够帮助更...
  • DSM是非常通用的抽象,这种通用使它难以在商业集群上实现高效率和容错。 方面 RDDs 分布式共享内存 读 粗/细粒度 细粒度 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,127
精华内容 4,050
关键字:

衡量边界稳定性