全屋定制施工图的监控体系建立过程简介

阅读量:

前言

施工图作为定制对接生产的利器, 当设计师通过设计工具完成场景设计之后, 就可以通过施工图出图功能, 快速生成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轮后端性能优化之后, 也同样是通过监控的实战验证, 为全友开放所有子账号的运营推广提供数据支持。

过程中, 也遇到用户经常上报生成视图的时候, 立面生成不正确, 或者是图框的宏数据展示不正确。我们借鉴交易对账系统, 我们建立从视图与模型关系入口着手, 建立成组, 立面, 宏的创建接口中, 视图与模型的关系监控项, 确保链路上的模型数量一致性。

最开始也说, 我们建立这个监控的目的是为了建立质量体系。所以借助监控, 我们收集典型回归场景, 补充接口测试场景。从而形成质量闭环。


comments powered by Disqus