定义
Report Analytics（报表分析）对设备数据、运维指标（MTTR、在线率、告警数等）进行统计、汇总与可视化展示。可与 BI、Tableau、Power BI 对接，支持自定义报表与导出。
核心指标与数据源
报表分析涵盖设备在线率、活跃设备数、告警统计、OTA 成功率、MTTR、设备健康分布等。数据源自 Time Series DB 时序库、设备元数据、Event Stream 事件流及工单系统。支持按产品、分组、区域、时间维度聚合；支持同比环比、趋势分析。平台可预置常用报表模板，或通过 Dashboard 仪表盘自定义看板。
与 BI 工具的对接
设备管理平台通过 OpenAPI 或 RESTful 接口暴露聚合数据，供 Tableau、Power BI、Grafana 等工具消费。支持定时导出、实时连接及 Webhook 推送。报表可嵌入业务系统、导出为 PDF/Excel，满足管理层汇报与合规审计需求。与 BI 平台深度集成时，可实现设备数据与 ERP、EAM 等业务数据的联合分析。
应用场景
适用于运维 KPI 看板、设备利用率分析、故障趋势报告、SLA 达成统计、成本分析等。报表分析是设备管理平台从「管设备」到「用数据」的关键能力，支撑运营决策与持续改进。
指标口径先于图表版式
报表分析首先固定每个数的分子、分母和时间边界，其次才是图表。在线若按“查询时刻会话还在”计算，和按“这一天里曾经连上过”计算，会得出两个不能对比的结果。修复时长若从告警产生算到工单关闭，中间包含等待配件的时间；若从有人开始处理算起，则只反映动手之后的耗时。同一张报表里混用这两种口径，环比上升无法解释。口径应写在指标定义里，而不是写在图例的脚注里让人自己猜。
统计还要声明数据从哪一层取出。原始遥测、按分钟聚合的均值、工单上手工填写的时长，三者不能相加。聚合层已经丢掉的尖峰，不能在报表里重新说成“没有越限”。导出的文件应带上口径版本和生成时间，避免两个月前导出的表和现在的同名表被放进同一份对比。改了口径却沿用旧名字，历史曲线会在切换日出现假台阶。
聚合粒度与采样周期匹配时
报表粒度可用的条件，是它不细于数据真正保留的粒度。设备五分钟上报一次，报表却按秒画出连续曲线，中间的点是插值，不能用来判断瞬时故障。反过来，只保留日汇总时，就不能回答“故障发生在上午还是下午”。选择粒度前先确认时序保留策略和工单时间字段是否完整，缺字段的记录应单独计数，不能悄悄从分母里去掉。
分组维度也要能在源数据里找到。按站点汇总的前提是每台设备在统计期内有唯一站点；中途调拨的设备要约定算在调出方、调入方，还是按小时切开。不约定的话，两张分站点报表的设备数相加会大于总数。与服务等级协议对照的报表只能使用协议里写明的指标，不能临时加一个更好看的替代数。管理层看的汇总和运维看的明细应能用同一标识钻取，汇总对不上明细时以明细的口径检查为准。
把在线率与活跃率混成一个数
在线描述连接是否存在，活跃描述统计期内有没有业务数据。长连接但不再上报测量值的设备，在线仍成立，活跃不成立。用在线率代替活跃率，会把已经停测的设备算成正常运行。相反，按上报次数定义在线，又会把正常的低频设备算成离线。两个指标应分列，并写明活跃所要求的消息类型：心跳不算业务上报。
升级成功率也容易被算宽。分母若只包含“已经回报结果的设备”，沉默的失败会消失，比率显得很好。分母应是任务计划覆盖的设备，分子才是在观察期内达到目标版本的设备，超时未回报单列。告警数量直接相加同样失真：一条根告警若派生出数十条重复通知，报表应能按抑制后的事件计数，同时保留原始条数供检查抑制是否过度。只展示原始条数，会让人把通知风暴理解成故障次数增加。
每次发布报表都保留一份和图表同时生成的明细索引，索引里是设备标识、统计窗口和该设备被计入或被排除的原因。读者对总数有疑问时，可以抽一台设备走完这个原因，而不是重新猜测公式。排除原因本身也要统计，例如未入网、已报废、时钟不可信、窗口内无样本。这些排除数若突然变多，往往说明采集或主数据出了问题，而不是业务指标真正变好。图表上的合计应等于计入项，两者不一致就停止对外发送这一期。对外发送前由不负责做表的人按索引重算至少一台样本，重算不一致则整期退回，不允许只改图上的标签。