共计 4477 个字符，预计需要花费 12 分钟才能阅读完成。
前言
Crash（造成用户无奈应用客户端所承载的服务）作为客户端稳固治理的最次要问题之一。云信作为国内业界当先的 RTC/IM PaaS 服务商，对于客户端 SDK（PaaS 服务商对外服务的次要载体）的 Crash 治理再器重也不为过。对于客户端 Crash 稳定性治理，只管业界已有多个成熟的监控平台，实现了从埋点、上报、展现到报警一站式服务，如 Bugly 平台、Fabric 平台等，也有 Crash 捕获的工具 SDK，不便在此基础上按需定制监控平台，如 KSCrash、Breakpad 等。但对于云信这样的 RTC&IM PaaS 服务商来讲，无论是市面上现有 APP Crash 治理平台，还是 Crash 捕获工具 SDK 都是无奈解决针对 PaaS 服务商 Crash 异样治理痛点。
• 平台类型反对无限
业内平台往往只笼罩支流的两个挪动端平台 iOS/Android、对于 Mac OS/PC/Linux/Flutter 不反对。
• APP 与 SDK 监控数据无奈无效隔离
业内对外服务的 Crash 收集平台根本都是设计服务于 APP，后盾剖析与展现无奈同时对 APP 和 SDK 进行辨别。
• 问题治理实现不了闭环解决
以业内驰名 Bugly 为例，只提供了对外闭源 SDK，Bugly 后端目前也没有凋谢第三方接口，解体信息都要人工去被动搜寻解决，无奈与 PaaS 服务商外部 Bug 管理系统进行联动，异样感知也没法主动感知与推送，造成不了 Crash 问题从捕捉到研发人员响应解决高效的闭环。
Crash 异样治理建设
为了解决以上 PaaS 服务商稳定性问题治理的痛点，构建一套从异样问题捕捉到研发人员高效问题解决的监控剖析零碎就显得分外火烧眉毛了，云信研发团队从以下三个维度思考：
• 如何实现数字体验监控：采集的指标有哪些，以及这些指标的影响是什么？
• 异样发现、跟踪及诊断：异样指标如何转化为具体可解决的计划，如何疾速找到问题模块？
• 面向技术人员的自动化运维：如何实现问题剖析的精准性，如何升高研发剖析耗时与老本？
通过大半年多的致力，终于落地了 Crash 稳定性治理平台（以下简称 Marvel）平台，实现了 Crash 问题的高效治理。该平台基于 PaaS 服务商的特点，设计了三级的账号体系，平台笼罩了 Android、iOS、Windows、MAC、Linux、Web 平台、Flutter 框架, 最终实现从问题捕捉、剖析解决问题、修复、复盘全链路的闭环，下文将针对该平台做较为具体的介绍。
平台架构设计
Marvel 平台架构设计图
如上图所示, 从数据流角度可知，当 CI 构建服务实现产品各个客户端平台 SDK 包的时候，零碎会主动将 SDK 包对应平台的符号表文件上传到 NOS（网易对象存储）文件服务，同时将 SDK 版本号、各个 SO 库的 build_id/uuid、Github 仓库地址等元信息记录到平台数据库中，为后续异样解析服务查找奔溃库所属的符号表文件做筹备。当 C 端产生 Crash 问题的时候，零碎首先会将 Crash 信息（栈信息、用户操作轨迹、uuid/build_id 等信息）上传到 Marvel 后盾服务，零碎通过数据荡涤以及异样解析之后，精准地剖析出该 Crash 属于哪个模块，平台反对依据模块归属人查问表或者依据 git commit 记录查找出最初代码变更人, 最终主动生成 Jira 工单，而后通过公司外部合作工具（POPO）同步异样待处理音讯给对应的研发同学。从而最终实现了线上异样解决的自动化闭环操作。
平台全景视图
Marvel 零碎全景视图
云信以后 Marvel 平台除了重点落地实现了 Crash 稳定性问题治理之外，同样也实现了局部平台其它稳定性问题的治理，如卡顿、内存透露、内存溢出、ANR、Watchdog 等客户端的稳定性问题，稳定性问题产生的上下文信息（用户的行为轨迹、利用的上下文等信息数据），通过 ES 搜索引擎和 HBASE 数据库实现海量数据的存储以及疾速数据聚合查问，最终可能疾速实现场景还原，实现问题的重现，最终实现疾速剖析定位问题。
账号体系设计
传统的异样捕捉零碎是基于 APP 维度来统计 Crash 等异样信息的，而作为 PaaS 服务商，心愿看到的是从 PaaS 服务产品及对应的 SDK 维度来统计 Crash 信息，因而云信设计了三级的账号体系，以反对每个层级来做聚合统计监控。
账号体系设计图
三级账号体系阐明如下：
• 公司级别。如易盾、云信等 PaaS 服务厂商。
• 公司产品 SKU。如云信有 IM SDK、RTC SDK、播放器 SDK。
• SKU 下的子产品。如 RTC SDK 下有美颜、背景替换、水印等插件化的子产品。
治理涵盖研发全周期
稳定性问题治理周期
稳定性问题治理须要贯通整个软件研发的残缺生命周期，包含需要研发、测试、集成、灰度、上线等，上述每个阶段，研发同学都应该分外器重稳定性问题的发现和治理。于是针对各个阶段的数据采集也就分外的重要，以后云信的稳定性问题治理平台曾经实现了线下场景的全笼罩，以及线上场景的局部笼罩。以后上传到平台的数据次要分为 Monitor、Logging、Tracing 三类。Trace 数据次要指的是代码调用栈数据；Log 次要是用户行为轨迹数据、客户端系统日志等；Monitor 数据次要是与人们异样模型相匹配的异样数据。
端侧功能集
端侧 Marvel SDK 功能模块
端侧 SDK 层面性能以小的颗粒度接入。在设计开发上实现采集性能的模块化，各个利用能够依据本身须要选择性援用功能模块，从而保障稳定性监控 SDK 对于利用的包体积及性能达到最小影响。除了提供原子的监控采集能力外，为了实现监控 SDK 的容错与容灾能力，Marvel 平台除了会对线上利用实时采集性能开关管制之外，监控 SDK 当遇到自身运行异样的时候也会主动进行性能敞开，对于问题可能做到主动隔离。
堆栈解析服务
在每个异样上报中，除了根底元信息外，还包含异样类型、异样音讯、异样堆栈等运行时内容，特地是堆栈信息，可能无效地帮助研发去辨认异样点。那么咱们就能够根据堆栈和异样类型来做聚合。
简略来说，能够依照堆栈信息做 Hash 比对来去重，尽管该计划可能大幅缩小反复异样，但还是会存在大量同类问题归结为不同类别的状况，例如在递归状况下的异样，递归深度不同就会导致 hash 后果不统一。思考 ROI 比以后咱们只截取非零碎的用户函数堆栈，前期思考引入些更高级的算法，对类似的堆栈可能更加精准的归因（如对堆栈间隔、TF-IDF 等伎俩对堆栈的内容进行解析，而后利用相应的公式来计算两个堆栈之间的相似性）。
从可察看性的指标来看堆栈信息对应就是 Tracing 数据，堆栈还原服务是决定后续是否能对问题进行精准剖析归因的要害。通过还原后堆栈信息 Marvel 能够疾速定位到代码行。然而线上运行时的程序为了平安和安装包体大小等因素，会对代码进行混同或者压缩，所以获取到的堆栈文本是混同压缩后的堆栈信息。为了使开发人员直观疾速地了解堆栈含意，这就须要应用相干的符号文件来对混同或者压缩的代码信息做还原解决。
客户端平台堆栈还原反对状况
晚期 Marvel 符号化解析次要依赖原生平台工具，但存在以下问题：
• 低性能
因为各个端提供的是命令行工具，所以须要在服务外部通过命令行调用，这种启动子过程的形式会带来大量的过程创立和销毁的性能损耗。此外，因为须要启动命令行子过程解决，解决跨过程通信也会带来较大的性能开销；通过命令行每次调用都要反复读取解析符号文件，带来了额定的性能开销。
• 难保护
因为命令行是通过子过程解决，无奈治理命令行子过程的状态，对命令行的异样的定位解决带来了复杂性；不同端的工具会依赖不同语言和运行环境，例如 iOS 的 atos 须要运行在 MacOS 环境下，这个对服务的对立部署十分不敌对。
为了解决以上问题，以后 Marvel 采纳 Rust 实现了各个端侧的符号解析，保障各个符号信息只做一次解析，并转为 KV 构造模式缓存解决。对立语言后也能升高程序运维复杂性，并服务 docker 容器化的需要。
以后堆栈还原相干的次要有两个服务：
• 符号表治理服务
负责符号表的上传、下载、解析、缓存等流程的治理。符号表上传之后，该模块会实时解析文件，并将其解析为 KV 的模式写入 Redis 缓存之中。同时，还会负责符号表文件存储和缓存的治理。
• 堆栈还原服务
负责堆栈还原，以 gRPC 的模式提供还原服务。当接管到还原申请时，会在 Redis 中查找相干的符号信息，并将这些信息拼接为残缺的堆栈，返回给申请发送端。
异样问题自动化散发
上一章节介绍了 Marvel 平台零碎的整体架构设计、账号体系设计、端侧功能集、堆栈解析服务等重点模块实现，本章节将重点解说平台对于 Crash 异样问题的高效散发解决。
一个高效稳定性治理平台, 主动精准散发异样的能力是必不可少的, 帮忙 PaaS 服务方疾速收到报警、疾速响应用户遇到的问题。对于零碎是如何依据堆栈信息来追踪与查问 Crash 解决研发人员了，上节第一 大节已具体阐明，这里就不再反复了。
问题散发云信以后次要采取以下两个策略:
• 蕴含业务堆栈的异样, 通过构建集成平台的组件保护人员信息, 间接指派到开发负责人。
• 对于没有业务栈帧的异样, 依据平台上我的项目创建人进行指派。
下文以 iOS 稳定性治理为例展现平台零碎实现。
- 聚类展现
Crash 异样问题聚类 UI 展现
- 异样链接推送
SDK 零碎异样链接推送告诉
- 工单创立告诉
POPO- JIRA 建单链接推送
- 平台异样与 Jira 关联
平台 Crash 异样与 Jira 关联
- 异样项与 CI 产物符号表关联
Crash 异样与 SDK 版本符号表关联
- 异样堆栈还原展现
Crash 异样堆栈还原图
总结与瞻望
以上就是云信研发团队对于客户端 Crash 稳定性问题治理与总结，文章针对 Marvel 平台的架构设计、账号体系设计、治理周期、端侧性能、堆栈解析服务等进行了具体论述。该平台的落地使得云信的研发效力失去了大大晋升。在 Marvel 平台上线前，Crash 等稳定性问题异样解决如下图所示，全流程人工作业，排查问题须要前后重复沟通，并且数据源齐全依赖终端用户配合导出解体数据，响应链路长并且往往存在短少数据源而没法定位的问题，产研侧也无奈被动感知线下 / 线上的稳定性问题。
旧流程：
新流程：
后续云信研发团队将持续从以下几方面进一步建设与欠缺 Marvel 平台。
欠缺端侧疑难杂症的问题治理
• 笼罩与欠缺更多端侧的稳定性问题治理；
• 如 Android oom 治理，欠缺内存治理伎俩与剖析，下一步欠缺问题断定规定。
一站式服务
端侧的问题并非孤立存在，它可能会受到后端的服务质量影响，双端的数据联通与关联可能为业务构建起残缺的利用品质地图。后续 Marvel 将与更多外部平台联动如后盾监控、后盾日志团队在数据服务上做联动，为应用服务提供一站式监控、定位、容灾服务能力。
智能归因剖析
本着数据驱动的理念，以及高效开掘并利用已有数据的思路。Marvel 后续将通过联合研发期间的数据，通过公布信息、代码变更信息、测试案例等，构建研发流程画像，同时联合线上观测数据与问题详情构建的线上品质画像，实现疾速聚合剖析归因，做到研发内问题提前预警，以及线上问题的在代码和责任人层面的根因剖析，升高研发排查问题的工夫耗费以及人员沟通老本，助力效力晋升。
