前言
施工图作为定制对接生产的利器， 当设计师通过设计工具完成场景设计之后， 就可以通过施工图出图功能， 快速生成dxf图纸， 对接工厂落地生产。 但是施工图作为行业特性较高的一个产品， 由于建模方式以及空间位置的不同， 出图结果千差万别，要在短时间内测试覆盖全场景是无法达成的。
所以， 为了保障线上质量， 施工图团队探索了多种保障手段， 例如业务巡检， 线上引流， 线上监控等手段实现线上产品的高质量， 并且取得了比较好的结果。
其中监控体系的建立耗时比较久， 但是取得的效果也是最大的， 因为它能全面快捷敏锐的反应线上的各种问题，同时降低了线上问题的排查成本， 所以把施工图线上监控的建立过程沉淀下来， 希望和大家一起探讨。
一. 业务背景介绍
为了 助力全行业实现“所见即所得”的愿景，一大重点是就是实现施工图的准确性和精细化。原先普通家装，较少有仔细的施工图，更多靠现场沟通与工人经验。所以往往成品和效果图有很大的出路。
定制施工图就为各商家提供了这样一个工具， 它可以独立编辑加工图纸， 预览， 标注以及根据图框配置获取生成所需的详细信息。将设计工具场景内的模型转换成符合生产工艺的各种视图。
二 . 监控体系大图
鉴于施工图的业务背景，单靠功能测试和自动化测试， 并不能保障完全符合商家出图工艺。所以我们还需要建立积极的线上监控系统， 将线上问题控制在最低的影响范围。先放一张我们建立的整体的监控大图， 下面再详细介绍建立的过程。
三. 监控建立过程
下面介绍我们建立监控体系的过程：
1.首先确定监控的目的
开篇我们介绍了施工图项目特性和重要性， 并且鉴于我们现有时间， 任务优先级， 资源安排等因素， 施工图上线初期是带着可控的已知bug上线试运行。我们期望能通过监控达到持续优化业务服务质量， 从而建立完善的质量体系的目的。为了达到这个目的， 我们就希望建立的监控系统能尽早尽快的发现更多的问题， 从整个业务链路， 从前端到后端能发现问题， 感知从硬件到软件的缺陷， 观察从内网到外网的整个研发流程的质量 。
2. 分析施工图的技术架构
明确了目标之后， 我们要深入分析业务的服务架构和数据链路， 这样才能把握业务核心， 找到关键节点和风险点， 制定相应的监控项。
定制前端通过parammodeldata将设计工具场景内的模型解析并转成图纸域的element。
到了图纸域， 根据数据对应关系， 一张图纸（Page）对应可以对应多个视图（View），一个视图中可能存在多个柜体的Grep信息，View可以通过其Parameter中的elementid列表确定视图中展示的GREP对应的柜体数据。由此可以看出， 在图纸域的展示内容来源核心数据是设计工具的modelid。
3. 确定监控指标
明确目标之后， 并结合业务结构之后， 我们开始层层分解的方式， 探索施工图的监控指标。
| 一级监控指标 | 二级监控指标 |
|---|---|
| 业务稳定性（请求量， 成功率， 和耗时以及关键业务场景的接口指标），观测业务的稳定性 | * 新用户数 * 用户留存率 * 视图生成任务处理时间 * 每个方案调用视图生成请求量 * 自动标注相关的监控 * 宏的计算耗时分布 * 定制渲染任务 modelPackageData 上传时间 * 自动立面相关监控 |
| 业务正确性（观测数据流向， 计算结果， 数据范围是否符合业务期望） | * 每个视图对应的请求体大小 * 图纸下载的速率 * 成组环境文件夹数量 * 视图对应手动立面数量 * 成组， 立面， 宏的对应视图的模型数据一致 |
| 质量数据，主要观测前端的用户错误请求数 | * 成组环境前端报错情况 * 视图管理器页面前端报错 |
| 服务数据， 主要关注服务的性能数据 | * 性能监控 b. 中间件的服务性能 |
| 应用监控 | * PU, QPM,磁盘等情况 b. 数据库实例 |
4. 确定监控手段
确定了监控指标后， 就开始寻找监控手段。除了工具， 我们还考虑了不同职责的人员在监控中能起的主动性。所以我们根据不同的指标， 确定了对应的监控手段。
| 一级监控指标 | 二级监控指标 | 监控手段 |
|---|---|---|
| 业务数据（请求量， 成功率， 和耗时），观测业务的稳定性 | 新用户数 用户留存率 视图生成任务处理时间 每个方案调用视图生成请求量 自动标注相关的监控 宏的计算耗时分布 定制渲染任务 modelPackageData 上传时间 自动立面相关监控 |
警报系统 监控平台 日志平台 故障台上报 运营和实施的实时反馈 数据小站 |
| 测试数据，观测测试活动的覆盖率， 以此来提高测试效能 | a. 每个视图对应的请求体大小 b. 图纸下载的速率 c. 成组环境文件夹数量 d.视图对应手动立面数量 e. 成组， 立面， 宏的对应视图的模型数据一致 |
监控系统 日志系统 通过商家微信群收集典型场景和方案 |
| 质量数据，主要观测前端的用户错误请款 | 成组环境前端报错情况 视图管理器页面前端报错 |
埋点系统 |
| 服务数据， 主要关注服务的性能数据 | a. 性能监控 b. 中间件的服务性能 |
监控系统 |
| 应用监控 | a. CPU, QPM,磁盘等情况 b. 数据库实例 |
监控系统 |
四. 监控数据
最后展示下， 我们监控体系的成果。
应用警报：
应用监控面板：
业务监控面板：
CF 统计线上问题反馈：
线上http巡检：
五.监控小结
监控系统还不够完善， 还在逐步过程中。当然， 我们也借助监控体系发现并解决很多问题。例如在0331~0423期间全友的每日发布， 就是依赖监控体系的快速感知达到及时修复。
并且在经过4轮后端性能优化之后， 也同样是通过监控的实战验证， 为全友开放所有子账号的运营推广提供数据支持。
过程中， 也遇到用户经常上报生成视图的时候， 立面生成不正确， 或者是图框的宏数据展示不正确。我们借鉴交易对账系统， 我们建立从视图与模型关系入口着手， 建立成组， 立面， 宏的创建接口中， 视图与模型的关系监控项， 确保链路上的模型数量一致性。
最开始也说， 我们建立这个监控的目的是为了建立质量体系。所以借助监控， 我们收集典型回归场景， 补充接口测试场景。从而形成质量闭环。