精华内容
下载资源
问答
  • 「崩溃」与「卡顿」、「异常退出」等一样,是影响App稳定性常见的三种情况。相关数据显示,当iOS的崩溃率超过0.8%,Android的崩溃率超过0.4%的时候,活跃用户有明显下降态势。它不仅会造成关键业务中断、用户留存率...

    友盟+移动开发专家 张文

     

    「崩溃」与「卡顿」、「异常退出」等一样,是影响App稳定性常见的三种情况。相关数据显示,当iOS的崩溃率超过0.8%,Android的崩溃率超过0.4%的时候,活跃用户有明显下降态势。它不仅会造成关键业务中断、用户留存率下降、品牌口碑变差等负面影响,而且会直接带来卸载和流失。也同时给开发者带来不可小觑的资本损失。

     

    那么,崩溃率低的App质量就高么?是否可以通过崩溃率直接判断App的稳定性?

     

    首先,衡量一个App质量好坏时我们需要定义一个统一的口径,即哪些指标可以作为稳定性的评估口径?以友盟+的U-APM定义的稳定率这个概念为例,评价一个App的稳定性和质量,一般从以下三点综合考虑:

     

    • 发生了崩溃,如java崩溃和Native崩溃,即用崩溃率这个指标来评估计算;
    •  发生了ANR,即用ANR率这个指标来评估计算;
    • 异常退出,如:low memory killer、任务列表中划掉、系统异常、断电、用户触发关机/重启等,即用异常率这个指标来评估计算。

     

    崩溃,也就是程序出现异常,导致程序退出。包括:

     

    •     Java崩溃,也就是在Java代码中出现了未捕获异常,导致程序异常退出。如:空指针异常、数组越界异常等。
    •     Native异常,也就是在Native代码中,出现错误产生相应的signal信号,导致程序异常退出。如:访问非法地址、地址对其  问题等。

     

    Java崩溃的捕获相对会简单一些,Native崩溃的捕获可能要求我们对系统底层知识要有一定的掌握。我们知道Android是基于Linux系统的,系统中的崩溃大多是由于编码错误或硬件错误导致的。当系统遇到不可恢复的错误时会通过异常中断的方式触发异常处理流程,这些中断的处理被统一为了信号量。当应用程序接收到某个信号量时会按照内核默认的动作处理,如Term、lgn、Core、Stop、Cont。同时我们也可以通过sigaction注册接收信号来指定处理动作,比如捕获崩溃信息等。当然捕获过程中也会有一些困难点,尤其在极端环境中,比如栈溢出时,由于栈空间已经被用完,造成我们的信号处理函数没法被调用,以至于无法捕获到崩溃信息,这时我们需要考虑使用signalstack,使我们的信号处理函数可以在堆里面分配到一块内存空间作为“可替换信号栈”来处理崩溃信息。

     

     

     

    当然,除了稳定、安全的捕获能力外,还需要丰富崩溃现场的上下文信息,比如Logcat信息、调用栈信息、设备信息、环境信息等等,为我们后续定位和解决问题提供全面的参考。

     

    对于发生崩溃的情况,我们使用崩溃率作为数据指标。包括:

     

    • UV崩溃率,也就是发生崩溃错误的去重用户/去重活跃总用户;
    • PV崩溃率,也就是发生崩溃错误的次数/启动次数;
    • 启动崩溃率,也就是应用启动过程中发生的崩溃,很容易被忽略但又非常重要的崩溃指标,因为启动是APP生命周期中非常重要的一个阶段,很多广告、闪屏、活动等内容都在这个过程中透出,同时启动时又需要加载各种初始化,并且如果启动出现错误,往往热修复、降级融灾策略都无法弥补。

     

    ANR,也就是Application Not Responding,当应用程序一段时间无法及时响应,则会弹出ANR对话框,让用户选择继续等待,还是强制关闭。从用户体验的角度看,有时候ANR可能要比崩溃会带来更糟糕的体验,所以开发者重视崩溃的同时也要非常重视ANR。

     

    ANR捕获的准确性一直是不断升级打怪、不断完善的过程。早期我们通过FileObserver 监听/data/anr/traces.txt文件的变化进行捕获和上报,但很遗憾随着版本升级,系统和厂商开始收紧系统文件的权限,此方案的覆盖设备情况越来越低,造成ANR捕获的准确性也一直降低。

     

    随后我们改进为监控消息队列的运行时间的方式捕获ANR,也就是向主线程Looper中放入一个空消息,监听该空消息在5秒后是否被执行,但该方案无法真实的捕获ANR情况(存在漏报和误报情况),并且也无法得到完整的ANR内容。后续我们参考Android ANR的实现原理,实现了一套实时、准确的ANR捕获方案,并且可以兼容所有系统版本。我们知道系统的system_server 进程在检测到 APP 出现 ANR 后,会向出现ANR 的进程发送 SIGQUIT (signal 3) 信号。默认情况,系统的 libart.so 会收到该信号,并调用 Java 虚拟机的 dump 方法生成 traces。

     

    我们通过拦截SIGQUT,在出现ANR时优先接收到信号,并生成traces和ANR日志,在处理完信号后,将信号继续传递给系统让系统生成traces文件,生成traces文件时,在保证内容与系统原生的一致性的同时还对生成traces文件的速度进行了明显的提升,有效地避免了可能因生成 traces 时间过长,而被 system_server 使用 SIGKILL (signal 9) 再次强杀,同时我们对捕获到的内容进行了丰富,包括:触发 ANR 的原因、手机中 TOP 进程CPU 使用率、ANR 进程中 TOP 线程 CPU 使用率、CPU 各核心处理时间分布情况、磁盘 IO 操作等待时长等重要信息,对分析、定位和解决 ANR 问题,提供了更加强有力的支撑!

     

     

    同样对于发生ANR的情况,我们也分为UV ANR率和PV ANR率,算法可参考如上崩溃率的计算。

     

    当然,除了崩溃和ANR,我们往往忽略了异常退出这种场景,但往往通过异常退出我们可以发现如low memory killer、系统重启等无法正常捕获到的问题。比如兼容性问题导致的闪退、设备重启、三方库主动调用exit函数,导致应用闪退次数增加等难以发现的问题,所以通过异常退出率我们可以比较全面的了解和衡量应用的稳定性。

     

    综上,对于文章开始的那个问题,我想大家都应该有答案了吧。当然,我们不应该为了掩盖代码质量问题,通过手动try catch去规避某些问题,这样有可能会打断用户的正常使用,并造成感知性的阻断反馈,应该从用户使用APP时的真实感知出发,当出现问题时及时捕获和处理问题。

     

    App的稳定性是一个长期不断迭代的过程,在这个过程中U-APM是一个很好的提升效率降低成本的工具,他提供了收集、解析、聚合、分析的能力,下一期我们会从如何通过U-APM解决和处理崩溃、ANR等问题进行讲解,敬请期待。


     

    展开全文
  • 基于MATLAB地震反应谱数值算法的稳定性和精度分析摘要:地震反应谱是进行结构抗震分析与设计的重要工具,反应谱的计算在反应谱法时域逐步积分方法中有重要地位,引起了学者的重视广泛研究。而对计算方法优劣的...

    基于MATLAB地震反应谱数值算法的稳定性和精度分析

    摘要:地震反应谱是进行结构抗震分析与设计的重要工具,反应谱的计算在反应谱法和时域逐步积分方法中有重要地位,引起了学者的重视和广泛研究。而对计算方法优劣的评定常取决于其计算的耗时、稳定性和精度等因素。本文基于数值算法的相关研究及应用现状,以MATLAB为平台,建立数值算法在不同影响因素下的三维图形,并结合理论进行对比分析。通过算例进一步分析验证,得出不同数值算法在实际计算中的表现,为工程实际计算中选取哪种积分算法更为合适提供参考。

    关键词:地震反应谱;时域逐步积分算法;稳定性和精度;MATLAB

    1、地震反应谱的基本假定

    地震反应谱基于的三个基本假设[1]:

    (1)结构物所处的地面假定为刚性面,认为体系各质点的运动是完全一致的。

    (2)强震观测仪的记录为地面运动的过程。

    (3)结构体系不能是双或多质点体系,必须是单质点体系;同时应是弹性体系状态。

    这里所谓的单自由度体系结构,就是用无量刚的弹性杆件支承于地面上,将结构体

    系中参与振动的质量用一点表示。同时,假定结构振动和地面运动不发生扭转,只是水平平移运动并且是单方向的。

    2、基于MATLAB地震反应谱数值算法的稳定性和精度分析

    2.1 概述

    目前MATLAB地震反应谱数值理论算法主要有中心差分法[2]、Wilson-法、Houbolt法、线性加速度法及Newmark-法等,理论算法主要是以求解线性结构体系动力方程时所表现出的特性作为数值算法优劣的评价依据[3],但是在实际工程运用中,人们常常凭借经验来判定选取较为合适的积分方法。

    随着工程问题越来越复杂,在对大型复杂结构的结构动力反应分析更为复杂,要求高效率计算情况下获得较精确地计算结果。然而各计算方法的精度和稳定性对结构动力反应分析的发

    ————————————

    E-mail:skyuanyan@http://www.doczj.com/doc/080c194e0c22590102029d9f.html

    展开全文
  • 系统之前是一个外采系统: B2P自闭环业务流程, 资产管理以及业财一致等业务功能集一身的单体应用系统. 随着业务发展,系统不断运维迭代,逐渐暴露出很多痛点,比如: 资产规模超出数据处理引擎原设计能力,性能不足严重...

    背景

    我目前主要负责供应链系统: 支持公司重资产业务持续精细化运营.
    系统之前是一个外采系统: B2P自闭环业务流程, 资产管理以及业财一致等业务功能集一身的单体应用系统.
    随着业务发展,系统不断运维迭代,逐渐暴露出很多痛点,比如:

    1. 资产规模超出数据处理引擎原设计能力,性能不足严重影响业务数据处理,月结.
    2. 技术架构过时(Struts,Ext,EJB等),不稳定,经常出现安全漏洞等问题
    3. 不能集成公司基础服务,出现问题,依赖原厂远程配合修复,维护性差

    基于以上主要痛点等因素,促使我们决定重构系统;目的就是系统稳定性建设.

    思考

    在准备重构之前,做了一些思考:我们的系统特性是什么? 怎样是系统稳定性? 围绕稳定性建设我要注意哪些?

    系统特性方面:

    1) 批处理系统(大数据处理时效),
    2) 财务核算系统(数据清晰明确),
    3) B2P系统(大表单业务逻辑),
    4) 资产库存管理系统(数据严格准确).

    稳定建设方面: 

    • 系统可靠性: 高可靠系统,故障次数少,频率低,在较长的时间内无故障地持续运行。
    • 系统可用性: 高可用系统,故障时间少,止损快,在任何给定的时刻都可以及时地工作。
    • 系统稳定性: 在系统可靠性和可用性基础上,即降低故障频次和提升止损速度的情况下,要求系统的性能稳定,不能时快时慢。

    总结,不仅需要系统尽可能随时提供服务,并且系统能提供有质量保障的服务。

    细节

    系统可靠性: 减少故障次数

    1. 系统故障复盘

    老系统(过往系统)的运营数据, 故障Case是一笔难得的财富, 对于今后系统重构提供有利依据. 所以充分的分析复盘是很值得的.

    1)  从点到面, 必须要深挖问题本质, 复盘过程中, 切记不可出现“忘了”, “好像”, “没仔细”, “没及时”,“时间不够”等敷衍, 太形式的字眼.
    2)  根据“重要紧急”, “重要不紧急”两个维度, 作出短期及中期, 且必须可真正落实的计划, 并且要明确责任人, 计划方案及DeadLine; 并持续跟进, 直到完成所有的todo.
    3)  必要事故, 明确故障责任人. 有错要认, 出了问题不能逃避要勇敢承担, 不要有“做多错多”的顾虑.制定合理“奖惩制度”, 做好奖惩平衡.

    2. 上线流程规范

    1)  主流程服务,必须经过CodeReview,才能上线.
    2)  主流程服务,必须经过测试回归, 准出确认,才能上线.
    3)  主流程服务,代码改动量大,影响范围大,必须选择不影响业务或低峰期时间上线, 且必须梳理并告知上下游可能影响范围.
    4)  上线流程,  严格按照流程计划中各个里程碑严格执行,并确认结果.

    3. 开发代码规范

    相信每个开发团队都有一套项目结构规范,  代码规范及CheckStyle措施,按照执行应该没有什么问题。但根据多年的踩坑经验及原有系统特性,要根据自身系统特性明确几条红线规范,如:
    1)  select语句,必须加limit;不可能需要把所有上百万,上千万的数据都查出来,容易把网卡打满.
    2)  select语句,where后面条件项,必须有一列是必选项,且该列是有索引的;千万级, 亿级数据的大表,因没走索引而导致全表扫描,很可能把数据库直接干挂。
    3)  update语句,要写单场景SQL,避免出现动态拼接的公用SQL,且where后面的条件项,必须有一列走索引,且该索引的区分度要高;update、delete为动态拼接SQL时,若漏传条件项,不仅IO效率很低, 并且会导致全表被修改或删除.
    4)  循环语句中,不允许进行rpc和db的IO操作,并且尽可能优化CPU的IO计算; 过多的循环,耗时长, 且可能把下游和db直接干挂。

    4. 请求防刷控制

    1)  外部,防止DDoS攻击;
    2) 内部,防止上下游服务,客户端等由于错误代码而频发刷新访问等情况.
    3) 具体实现策略相对成熟, 如:

    MQ幂等校验; 通过用户IP及方法设置防刷阈值; 服务间做鉴权验签访问等.

    此外, 如果对于可靠性要求很高的核心服务, 要尽可能保证两个原则:

    1)  最小链路闭环, 尽量少依赖其他服务, 尽量少依赖中间件.
    2)  最大限度隔离, 不相干非核心服务, 尽量隔离部署.

    5. 压测限流控制

    评估系统峰值流量, 预估未来可预见的发展情况; 通过数据回流方式进行压测以保证业务处理能力的同时, 再通过QA对系统服务能力进行专业压测.
    根据压测出的阈值, 做出必要的限流,告警等措施; 避免系统服务过载而挂掉.

    系统可用性: 缩短故障时间, 及时响应止损  (故障时长=发现问题时长+定位问题时长+解决问题时长)

    1. 上线流程规范

    此处再提上线规范的出发点不同: 基于系统可用性的上线规范, 主要从问题的发现, 定位, 解决来思考.

    指标检查: 在预发环境(有条件的话尽可能用灰度环境: 最接近于生产环境)测试过程中, 除了正常的业务功能测试, 要从三个方面来着重持续观察:

    1)  基础指标: 服务器CPU, 内存, IO, 网络, JVM, GC等是否正常
    2) 应用指标: 服务接口QPS, TPS, RT等, 考虑是否有明显异常需要优化
    3) 业务指标: 必要核心主流程Case(支付相关等)走一遍, 是否正常使用, 后台是否会暴露异常日志等

    回滚方案: 如果在上线后, 发现仍有未知指标异常, 且不能及时处理的情况下, 针对本次上线要做合理可行的回滚方案.
    常见的回滚方案考虑方面有: 代码回滚, 表结构回滚, 数据回滚, 以及程序流量开关切换等.

    2. 系统监控告警

    监控告警主要解决发现问题的时长.

    针对上面所说的三个指标做监控, 进行日常巡查, 保证发现问题时, 一定是先收到系统自身监控告警, 而不是通过用户先来反馈.
    此外, 报警也需要有标准: 告警要做到数据精准, 级别明确; 不能存在过多的报警, 尤其是误报; 过多的告警等于没有告警, 误报等于“狼来了”, 反而会让大家忽视掉有用的告警: 对问题发现,处理不及时. (每天成白上千个邮件告警没有人会仔细看)

    3. 系统应急预案

    应急预案主要解决定位问题及解决问题.

    通过经验及过往Case的案例, 及时总结沉淀文档, 明确处理步骤; 尽可能做到发生同类问题, 任何一个人都可以“无脑”按步骤进行处理.
    此外, 预案肯定不是“死的”(plan is nothing, planning is everything.) 是要随着技术架构, 运维迭代, 业务发展来不断更新, 必须做好“断舍离“;不能把预案做的越来越重, 越来越难懂.

    4. 系统故障演练

    故障演练主要从已知,半知,未知三个方面来准备

    已知: 已经发生过的故障Case, 按照应急预案演练去做, 熟能生巧
    半知: 从已知中, 思考发现未知因素, 进而补充预案
    未知: 若发生未知故障, 需要有临时决策方案, 安排人员有序排查定位; 采用系统版本回滚等方案尝试解决问题; 或确定问题原因及解决方案后, 采用应急临时解决方案等. 尽可能缩短故障时间.

    5. 系统自动防御

    这方面经验比较少, 可想到的是需要我们在开发过程中多思考, 每个环节都要有安全意识, 逆向思维; 比如:
    1) 当下游依赖核心服务不可用, 失败重试及失败时间阈值, 可服务降级方案等
    2) 当下游依赖基础服务不可用, 上有流量激增而导致不可用时, 可服务熔断,补偿机制等

    总结

    我认为对于系统可靠性及可用性建设肯定是重要且紧急的事情, 但系统稳定性建设属于重要, 但没那么紧急的事情. 因为保证系统稳定是需要坚持的长期工作.

    我一直认为再牛逼的技术也要作用在合适的业务上; 没有最好技术, 只有适合技术. 在做系统稳定建设的过程中, 要随着业务迭代发展, 技术方案跟着演进: 服务拆分,水平拆分,垂直拆分,冷热分离,技术选型等等; 且尽可能不自己造车, 复用现有且成熟技术经验; 没有一粒银弹能解决所有问题, 站在巨人的肩膀上强大起来.

    系统稳定性建设,我们依然在路上.

    展开全文
  • 偶尔翻了网上关于指标一致性的文章,都不是很满意,手打的,没有排版,见谅 当下大数据下,数据指标不一致带来的问题 1,多版本问题,同一个指偶尔翻了网上关于指标一致性的文章,都不是很满意,手打的,没有排版,...

    偶尔翻了网上关于指标一致性的文章,都不是很满意,手打的,没有排版,见谅

    当下大数据下,数据指标不一致带来的问题:

    1,多版本问题,同一个指标有不同的版本

    2,各业务系统自行管理指标,无法形成统一的解释,数据质量较差

    3,数据指标格式混乱,每个系统同一个指标都定义了不同的格式,描述差异大

    指标一致性的意义:

    1,确立企业内部标准,推动数据系统化落地

    2,全面整治历史数据,从根本解决这部分历史顽疾

    3,形成制度化、准确化、流程化的指标管理体系,杜绝此类问题再次发生

    4,促进业务系统和数据平台协同联动需求,为企业资料共享、快速决策提供提供规范的、标准的信息化服务,是企业数据价值的更好的体现。

    指标一致性的模式:

    1 原数据指标一致,主要指的是 静态指标一致,主数据一致,编码一致是从业务系统,日志采集进行规范和改造的,改造后的指标亦会再次回流至业务系统(如果是此类型数据),目前大多数大型公司采用此方案

    2 末端指标一致,通过对ods层的数据指标干预清洗,深层次的解决此类问题,目前方案较成熟

    3 ai指标一致,通过和ai自动识别结合,自动识别异常指标进行制定规则,目前尚不成熟

    指标一致性管理的原则:

    1 自上而下指标体系

    2 指标标准直至末端

    3 强调指标针对性,只针对管理,不宜过多受业务影响

    4 不宜过细 ,只初步确认,不要过于纠结个别细节

    5 明确管理需求

    指标规范化问题:

    1 指标大类问题,如大类纬度不统一

    2 指标中类问题 ,如中类指标范围过广

    3 指标小类问题,如指标小类模糊不清

    4 指标编码属性问题,编码模型不统一,一码多物或一物多码的问题。

    5 指标计量单位问题,如大小写不同,书写格式不规范。

    等等

    指标统一性的目标 长久性,前瞻性,全面性,可扩展性,稳定性实用性,合理性,可审计性等等

    展开全文
  • App的稳定性时一个长期不断迭代的过程,在这个过程中U-APM是一个很好的提升效率降低成本的工具,他提供了收集、解析、聚合、分析的能力,下一期我们会从如何通过U-APM解决处理崩溃、ANR等问题进行讲解,尽情期待...
  • 阿里巴巴稳定性保障体系

    千次阅读 2021-01-24 18:27:41
    阿里巴巴稳定性保障体系 作者介绍 步崖,曾就职于阿里巴巴蚂蚁金服。熟悉高并发、高可用架构,稳定性保障等。热衷于技术研究分享,发表过”分布式事务”、”分布式缓存”等多篇文章被广泛阅读转载 ...
  • 数据仓库之数据质量建设(深度好文)

    千次阅读 多人点赞 2021-09-24 11:17:29
    当然是数据质量治理,因为数据质量是数据分析结论有效性和准确的基础,也是这一切的前提。所以如何保障数据质量,确保数据可用是数据仓库建设中不容忽视的环节。 本文首发于公众号【五分钟学大数据】,完整的...
  • 点击上方“机器学习与生成对抗网络”,关注星标获取有趣、好玩的前沿干货!‍作者:Chu-Tak Li编译:ronghuaiyang AI公园‍‍导读‍‍全局一致让图像补全的内容契合上下文...
  • 文娱妹导读:质量保障贯穿全部研发流程,测试作为质量的构建者守护者,需要保障的不仅仅是提测后的功能质量,而是整个研发过程的质量和效率。分享优酷通过质量保障建设提升研发效率和质量的实践过程。 仔细阅读...
  • 浅谈系统实现层面稳定性保障

    千次阅读 2021-02-23 16:20:00
    稳定性保障围绕的核心 稳定性保障涉及机房、网络、硬件部署到业务场景、交互设计,再到应用架构代码质量、流量与封网管控、攻防复盘等,是一项非常系统化的工程。而分工协作使得上述大部分工作流程化标准化,比如...
  • 阶段性总结下我自己从团队技术负责人视角做好稳定性建设的实践性思考简要思路,为感兴趣的技术同学提供一个实践指南。 我的团队稳定性建设思路包括了3大技术要素:良好的系统架构实现、完...
  • 本文作者以团队技术负责人的视角,从三大技术要素一个业务要素,分享在稳定性建设上的实践性思考简要思路。希望对同学们有所启发。 一 概述 自己以及带领的团队曾经负责较多不同类型的互联网服务系统,如几...
  • 最近看到一篇论文,是探讨关于NER数据标注中标签一致性问题的。数据标注在建立基准确保使用正确的信息来学习NER模型方面起着至关重要的作用。要想获得准确的标签,不仅需要时...
  • 2.极好的稳定性: 罗斯蒙特变送器的测量会随着环境温度、过程温度、静压的变化而发生漂移,如果在一些微小的压力、差压测量场合,这个漂移很可能是比较严重的,会存在一个很大的误差。但3051变送器由于具有独特的...
  • ACL-gan对抗一致性损失

    2021-08-06 15:43:20
    对抗性一致性损失与周期一致性损失的比较。蓝色矩形绿色矩形分别表示图像域ST。矩形内的任意点表示该域中的特定图像。(右):给定源图像xS,周期一致性损失要求将图像翻译回来,ˆxS,应该与源图像xS相同。(左):...
  • 系统稳定性

    2021-04-23 15:46:14
    三、稳定性建设四要素 第一要素:人 第二要素:工具 第三要素:预案 第四要素:目标 四、稳定性建设四个方向 第一个方向:根基要抓牢(45%) 第二个方向:工作在日常(30%) 第三个方向:预案是关键(15%) ...
  • 点击上方“AI公园”,关注公众号,选择加“星标“或“置顶”作者:Chu-Tak Li编译:ronghuaiyang导读全局一致让图像补全的内容契合上下文,局部一致性让纹理更加真实。欢迎大家...
  • 后起之秀——CAN FD:随着各个行业的快速发展,消费者对汽车电子智能化的诉求...一致性测试是用来检测零部件是否符合相关标准的测试流程,从而保证产品质量。 在CAN FD网络中,各节点的质量不一致可能会引发错误..
  • 其实,我个人觉得这些都是过程,站在最终的结果导向上来看,数仓的痛点就在于如何保障数据的一致性,正确性时效性的统一,目前看来前路应该是流批一体。 单就目前还是流批分离的情况下,离线数仓在一致性和正确性...
  • 简介: 年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的...
  • 系统稳定性大纲

    2021-03-19 15:17:08
    软件系统的稳定性,主要决定于整体的系统架构设计,然而也不可忽略编程的细节,正所谓“千里之堤,溃于蚁穴”,一旦考虑不周,看似无关紧要的代码片段可能会带来整体软件系统的崩溃。 稳定性的工作,一般都是水下的...
  • 本内容来自“技术琐话”每周直播,公众号回复“高德打车”可下载pdf。文末有视频回放链接。招聘插入: 高德打车JD 岗位职责: 1.负责高德共享出行系统架构重构持续演进,保障核心交易链...
  • 经历了大小数以百计的事故后,从 82 原则上看,我发现 20% 是因为人员能力机制流程的欠缺,80% 则是因为人员的稳定性意识不足,并且故障应对方法不当。而作为技术 Leader 的你,如何认识稳定性、如何应对故障、...
  • DTC:通过双任务一致性进行半监督医学图像分割1、水平集衍生的分割图1.1 水平集方法(Level Set Method)2、水平集方法(the level set method,LSM)水平集方法为甚么能够在分割中有良好的使用呢? 本文主要是将“DTC...
  • 动态静态平衡、防止跌倒、控制器稳定性、平稳的人-外骨骼交互. 文章主要介绍: 下降识别(疑问)、平衡恢复、稳定性保证策略. 在平衡稳定方面主要采用: 零力矩点(ZMP)、质心(CoM)、外推质心(XcoM). ...
  • IT系统规模越来越大、集中度高、架构复杂、耦合度增强,使得业务技术复杂度越来越高,测试设计测试实施难度大,IT系统质量保障压力持续加大。 2、测试周期越来越短 业务需求提出到 IT 实现的周期越来越短,...
  • 最近面试业务测试有被问到如何保障测试效率测试质量的问题,结合目前工作中使用情况,总结出以下几点: 1、测试从需求阶段开始介入,从需求评审开始跟进,了解项目的各个阶段 2、在需求、UE、UI评审完成之后,...
  • 本篇文章主要内容 数据缓存 为何要使用缓存 哪类数据适合缓存 缓存的利与弊 如何保证缓存数据库一致性 不更新缓存,而是删除缓存 先操作缓存,还是先操作数据库 非要保证数据库缓存数据强一致该怎么办 缓存...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 83,470
精华内容 33,388
关键字:

关于质量的稳定性和一致性