标签：imageview 一键 关注 脚本 验证 http 测试 依赖 lazy
1.监控的核心能力是什么？
报警的有效覆盖率、线上问题的发现能力以及如何快速定位问题。
2.安全生产的整体目标是什么？
1-5-10，1 分钟发现问题、5 分钟定位问题、10 分钟修复问题。
3.为什么多数故障不能被发现？
业务未接入监控：安全意识缺乏、基础设施并不完备
核心指标未订阅：多数页面引入了监控，但是没有订阅报警，或者指标订阅不全。
监控指标不完整：只关注了页面运行时的异常，没有关注 CDN 节点异常、页面加载白屏、页面执行 Crash 等问题。
4.为什么快速恢复很难？
一个完整的开发流程包含 ：开发 -> 发布 -> 线上验证回归流程
如下图所示：
按这个流程很难做到 10 分钟恢复，怎么办呢？
聚焦到页面发布之前的开发阶段和发布阶段：
发布之前：完整的自动化测试流程，例如在发布之前对资源异常、JSError 等做检测拦截。
发布过程：页面发布过程具有可灰度、可监控、可回滚的完整过程。
5.整体方案是什么？
5.1 提升监控覆盖率
1. 提升接入覆盖率
完善基础设施：在搭建层做默认统一接入，在源码层统一采集规范和数据规范。
业务治理推动：通过统计团队维度的覆盖分布和指标情况，度量页面安全分（度量&红黑榜），引导和推动其快速接入。
2. 提升订阅覆盖率：
订阅指标补齐：通过治理流程，统计页面未订阅关系分布，走一键订阅指标补齐。
完善发布流程：页面发布后，订阅发布消息，对核心指标做增量订阅。
3. 提升指标覆盖率：从安全视角来看，整个链路（从容器启动 -> air渲染 -> 页面加载执行）的稳定性都需要做到可监控。
容器层：比如 webview 容器等，加载运行过程可以检测页面加载是否白屏 和 crash。
源站层：在 CDN 就出现异常，从前端的视角是无法感知的。
页面层，依赖本身 SDK 的能力，全局捕捉过程异常点作为监控指标点。
全链路保障过程，在数据链路层对数据指标过程做了统一接入，通过页面地址对齐指标：
5.2 灰度监控区分新版问题
快速恢复的核心是需要更快发现问题，更快的对变更进行回滚。数据表明，80% 的线上问题是由变更导致的，而这些故障都有监控，只是新版本的问题在错误量上不明显，又没有专门的区分，导致被忽略。
所以对于变更的过程的监控【灰度监控】需要标识异常日志，判断是否是新版本带来的。
解决方案如下：
指标采集：采集脚本通过读取模板全局变量获取，容器层通过 response header 拿到灰度标识。
监控指标：采集脚本和容器层需要统一和标准化灰度字段规范，在日志上报过程中携带，小程序通过版本号区分。
灰度应用：主要表现在指标灰度实时日志呈现和报警。
标签：imageview 一键 关注 脚本 验证 http 测试 依赖 lazy
原文地址：https://www.cnblogs.com/software-test-Python/p/14636989.html
