一、背景
在快速迭代的业务需求下，难免会出现一些线上 bug ，特别是在 SaaS 业务领域，线上 bug 对于商家来说大概率会影响经营，严重的话很可能引发故障。所以，我们对线上质量要求很高。针对线上 bug ，除了商家主动上报问题，后端还有自己的天网监控体系，进行主动发现问题，那移动端如何进行主动防控呢？所以我们也需要自己的主动防控平台。
为什么不可以直接使用后端的天网系统？
需求功能对比
从功能来看，后端的天网更像一个线上接口日志存储，结合监控配置能力进行预警处理。经过分析，后端天网无法满足移动端的使用场景。
核心价值
提高客户端线上质量，减少线上问题，主动发现与预防线上问题，及时报警与处理，降低线上问题的影响面。做到防患于未然。
二、整体设计
根据以上背景，可以得知，移动端天网平台相对于后端天网平台更复杂，涉及的技术点也比较多，主要有客户端、 PC 后台管理（下面内容简称 mpaas ）、后端服务、数据存储等。
系统架构图
整体流程是可以区分两部分，一部分为日志上报流程，数据来源是业务方客户端，另一部分为日志操作流程，操作方是 mpaas 后台。这两者的区别，主要是一个是数据的来源方，另一个是数据的使用方。
日志上报流程
客户端上处理流程相对来说没有那么复杂，主要就是数据的采集与上报。其中核心逻辑都在业务服务中进行，比如日志内容整合，触发通知逻辑等。
日志操作流程
mpaas 平台，是整个处理和报警的核心。提供问题查看、分配人员、状态变更、问题备注、通知策略等功能。
后端天网系统（ skyLog ）
为什么我们自己做了数据存储以及移动天网平台，为什么还会依赖 skyLog 呢？
主要原因是，我们天网上报数据是区分等级，存在 info 、warning 、error 三个等级，对应上报问题等级不同，通知策略与处理流程也会有区别，但都是需要记录到 skyLog 日志平台上，类似打 log 日志。目前 info 级别的数据是不会存储到移动天网服务中，因为打日志内容不在报警范围内，所以查询打的日志内容就需要到 skyLog 平台上查询。具体两者区别参考前面第一部分背景介绍。
企业微信服务
公司内部使用企业微信，针对企业微信可以自定义消息通知以及群机器人功能，可以使用企微提供的公开接口进行调用，很方便的实现通知报警能力，可针对不同业务场景，定制不同消息通知。针对本平台，当触发报警，比如 error 级别问题上报（后面会有具体通知策略分析），则会通过消息给负责人推送系统消息，以及群机器人触发报警。
例：零售移动天网报警群机器人
具体使用参考企业微信官网 api：https://work.weixin.qq.com/api/doc/90000/90135/90235
三、日志采集和上报
目前该平台对接的业务方，主要是针对的是公司各业务团队的移动端业务，日志的上报基础能力集中 Zanlogger 日志二方库。同时基于目前混合开发的现状，开发了 ZanlogWeex 和 ZanlogFlutterPlugin 来实现 Flutter 和 Weex 页面的日志需求。
1、日志信息采集
首先看下日志内容的组成：
其中，基础信息由 Zanlogger 自主收集，业务方使用的时候，只需关注相关业务信息。
//天网日志上报
Log.sky("info", "sale", "startPay", "goods is xxxxx")
Log.sky("warn", "sale", "changePriceFailed", "goods is xxxxx")
Log.sky("error", "sale", "db can not open", "error:xxxx")设备型号，系统 os 版本，应用版本，用户 id ，店铺 id 等基础信息，在同个设备的大部分时间段内，都是相同的。考虑到流量和效率问题，没必要每条日志都上传。
Zanlogger 的实现方式是，应用启动时，获取设备唯一标识，上传一次基础信息。业务日志上报时，只需上传设备唯一标识。后端服务收到消息时，通过唯一标识获取基础信息，组合成完整的日志。
2、按级别策略上报
移动天网平台支持 error，warning，info 三种级别的日志上报，针对不同级别的上报信息，触发接口上报的时机也不同。
error : 最高等级问题，如果发生，则会引发线上 bug ，客户端会立即上报。
warning : 该级别我们定义为警告，针对一些业务场景，可能是异常或其他系统错误，发生并不一定是线上 bug ，然而当短时间内发生次数过多，则可能演变成线上 bug，所以该问题不会立即上报，而是存在一定 buffer ，当发生次数到达 buffer 量级后客户端进行上报。
info : 低等级问题。该级别我们认为是基础日志信息，并不认为是问题，基本是业务人员进行埋点数据进行线上逻辑排查与跟踪使用，客户端上报策略和 warning 类似，也存在 buffer ，达到量级后进行上报。该级不会进行通知，相关人员自行去天网日志平台中查询信息。
为了担心数据量太小，buffer 一直未达到上报的条件，或者网络原因，但是一直上传失败，同时会设置指定时间（例如 30s ）的轮询机制，一旦发现有未上传的日志，立即上报。
四、日志存储和报警设计
1、日志存储
实际场景中，日志的上报频率，和日志的内容大小是不确定的，基于性能考虑，后端的数据存储流程如下：
原因是，相较于 RDS ，HBase 更适合适合大数量的存储，于是日志完整内容存放在 HBase，两者通过每条日志存储时，生成的 uuid 关联。日志的频繁上报，使用 kafka ，保证峰值处理能力。
存储位置的问题解决后，接下来思考的是日志该以什么维度进行分组？
移动日志的解决方案是聚合 biz + sign + type + level + os ，取其 hashcode 。
这里为什么会将系统 os 作为分组因子呢？这里的原因是，基于现有场景分析，存在 pad 和 phone 同一个 sign 的报警，大概率是不同的代码流程导致的，应该视为不同问题去排查和分析。
2、报警策略设计
当 error 日志上报后，后端会通过企业微信服务，向指定的群发送消息，并且 @指定的人，影响范围大的问题甚至需要 @所有人。信息论中有个定律：“信息量越大，信息熵越小”，所以为了保证群消息的关注度，在保证关键信息触达的前提下，对群内成员减少不必要的打扰。
因此不是所有信息都需要发送到群消息，比较建议群通知的场景如下：
新问题出现。
已解决问题新版本再次出现。
阈值范围报警。
以上是我们提供的默认配置，也支持让业务方自定义。下一章节中会讲到相关自定义配置功能。
报警策略流程中需要用到以下概念：
问题状态：上报问题处理的状态，分为待处理、处理中、待发版、已上线。
问题解决版本：当问题状态变更到待发版或已上线时，需要填写解决版本号，比如 6.5.0 ，代表该问题在该版本已解决。
完整的报警策略流程如下：
五、移动天网平台可视化介绍
该平台的核心功能就是对于上报问题的报警通知能力与处理能力，以及相关报警配置策略。这里对于客户端的上报相关没有什么可讲的，相关的数据上报策略前面也有讲。这里主要针对 mpaas 平台进行功能与策略介绍。
1、问题查看
问题列表页面：
问题列表主要展示上报的所有问题，上报时相同的问题会进行聚合，列表中每一条数据，代表相同一类问题。同时支持多种筛选条件进行快速查找。
业务：针对不同客户端的业务方
平台：iOS、Android、PC 等
版本：上报问题的 app 版本信息
类型：各业务方定义自己的问题分类 type ，比如零售定义为业务模块
sign：上报问题的 key ，用来标识问题名称
等级：前面也有讲到，分为三个等级，error、warning、info
时间：进行时间段筛选
处理状态：用于筛选具体问题状态，多选
处理人：问题相关处理人
关联问题文档：用来快速筛选出带有关联问题链接的问题
问题详情页面：
针对每一类问题，点击详情进行查看上报的具体信息。详情中，会包含该类问题的所有上报信息，每次上报问题都可以查看具体上报内容信息，然后进行问题分析。
拉取设备离线日志：可以快速拉取上报问题设备的本地离线日志
操作记录：记录该问题的操作情况，以及该问题解决过程中的备注
2、问题处理
当问题上报上来时，会默认进行分配给上一次处理该问题的人员，如果是新问题则会分配给对应业务 owner 进行处理。当问题在解决时，需要对问题人员及状态等进行变更。
针对问题处理的操作，主要有状态、人员、备注信息。如果状态为待发版或者已上线，则需要填写修复版本，用来保证该问题在低版本的误报情况，如果问题存在问题链接，则需要填写关联问题文档，方便后续查看与统计使用。
状态：分为四个状态，待处理、处理中、待发版、已上线
处理人：根据公司内部员工信息，对应到内部人员信息
备注：操作该问题时，需要填写备注信息，以便后者人员进行查看
修复版本：该问题的解决版本，当状态为待发版或已上线时需要填写
问题文档：该问题关联的问题链接，非必填
2h 内免打扰：当有人在处理时，为了专心解决问题，可以设置 2h 免打扰
3、报警策略相关配置
前面有讲到，报警能力主要依赖企业微信进行通知到相关的人和群。实现自定义报警策略，那就需要相关策略配置功能页面。
3.1 配置后台页面
报警策略列表页面：
报警策略配置页面：
配置页面可以根据业务方需求，自行添加应用配置策略，可根据 error 和 warning 级别分别设置配置策略信息。在问题上报后，会根据不用业务方应用（ biz ）进行识别，采用对应的配置信息进行报警。
3.2 通知模板
通知模板主要分为三类，个人及群消息通知，日报和周报。
问题消息通知
日报和周报
个人及群消息通知，主要是针对新问题及操作变更时进行通知。日报和周报更多的是关注统计相关的数据，针对上报问题日报情况，可以看出当日问题的处理情况，周报数量统计，可以看出本周的概要情况。
四、总结
对于移动端来说，线上问题的发生是比较严重的问题，特别是在零售这种线下场景，很可能一个问题会给商家带来资损的问题，所以对于移动端的质量问题要有高标准。除了开发阶段的 code review 和自测，测试阶段的自动化测试和人工测试，我们如何主动监控线上问题的发生就成了关键，移动天网平台的搭建就是解决线上主动监控的空缺。
目前移动天网平台在线上已经跑了近半年时间，其中有效帮助移动端主动发现线上问题数量占比已经达到 20% 。对于主动发现的问题，我们快速响应进行解决，目前主动发现的问题商家没有再进行上报。这对于商家和服务同学，以及开发都是一种效率和质量的提升。
end