巡检周报自动生成：三张表拼成一页

每周五下午，以前是运维组集体头疼的时间：三个人分头整理一周巡检记录，手工拼一份周报给部门负责人，格式来回调，数字来回核，一个下午就耗在这上面，周五的正事反而得往后推。去年用系统把这件事自动化之后，周报周五中午就躺在负责人的收件箱里，值班的三个人多出半天干正事，周五下午从此还给了真正的运维工作。这篇记录实现思路。结论先行：周报自动化的本质是把散在三张表里的数据，按固定口径聚合一页，数据源头干净了，报表就是一层薄薄的壳；源头脏着，再漂亮的自动化也只是把脏数据搬运得更快。

一、手工周报的老问题

1.1 一份周报的三个人工

老流程拆开看：值班员从巡检系统导出巡检执行记录，这是头一张表；值班长从工单系统导出故障和维修记录，第二张表；我再把资产台账里设备状态变化的部分拎出来，第三张表。三张表在电子表格里手工对齐：巡检覆盖率怎么算、故障怎么分类归因、哪台设备该点名，口径都在各人脑子里，同一件事这周算紧急故障下周算一般异常，负责人看了两次就打电话来问，报的人答不上，问的人更糊涂。

1.2 数字对不上的尴尬

最尴尬的是数字对不上。周报里写本周巡检完成三百二十项，负责人翻出上周的周报问为什么上周是三百四十五项，没人能立刻说清是点位调整了还是漏检了。原因很简单：每周导出数据的时间点不一致，有人周五下午两点导，有人四点导，中间两小时的记录就飘了。手工报表的数字看似精确，实际经不起追问，因为口径藏在操作习惯里。

1.3 目标：中午自动出周报

改造目标定得很朴素：每周五中午十二点，系统自动生成上周五正午到本周五正午的周报，口径固定、数字可回溯、直接送达收件人。正午到正午这个窗口是特意选的——工作日的白天做窗口边界，凌晨截断反而会把夜间批处理的数字劈成两半，周报偏偏还集中在周五看，错位感更强。怎么选窗口，本质是理解自己业务的节奏，不是套别人的模板。

二、三张表的设计

2.1 巡检执行表：记录原始事实

头一张表管巡检，字段保持朴素：

CREATE TABLE patrol_exec (
  id         BIGINT PRIMARY KEY AUTO_INCREMENT,
  plan_id    INT      NOT NULL,           -- 巡检计划
  point_id   INT      NOT NULL,           -- 点位
  executor   VARCHAR(16) NOT NULL,        -- 执行人
  exec_time  DATETIME NOT NULL,           -- 扫码时间
  result     TINYINT  NOT NULL,           -- 1正常 2异常 4跳过
  KEY idx_week (exec_time, plan_id)
);

设计要点是只记事实不下结论：扫码时间、结果状态、执行人，是什么记什么。覆盖率、漏检率这些结论性数字全部放到报表层现算，事实层永远干净。曾经想过在表里加个合格标志字段方便统计，后来意识到那是把结论混进事实，口径一改就得刷全表，就此打住。事实层的克制，换来的是统计层的自由，这笔账怎么算都划算。

2.2 工单表：故障的生命周期

第二张表管工单，核心是状态流转的完整记录：创建、分派、接单、处理、验证、关闭，每次流转带时间戳。周报要的三个数字——本周新增、本周关闭、平均处理时长——全部从流转时间戳推出来。有了完整流转记录，任何单子的处理过程都能回放，负责人问到某个具体工单，点开时间线就是全过程，不用再找人补口头说明，工单处理的透明度，靠的就是这串时间戳的完整。

2.3 资产状态表：变化才是新闻

第三张表管设备资产状态。台账本身不动，动的是一张状态变更日志表：设备从运行转停机、从停机转报废，每次变更记一笔。周报里的设备动态栏目就从这张日志表取数，只报变化，不报存量——存量在台账系统里随时可查，周报的职责是把这一周值得注意的变化推到负责人眼前，而不是把台账抄一遍，读者要看的是动向，不是名录。变化即新闻，这张表的定位就是新闻素材库。

三、周报的拼装

3.1 口径先落成配置

拼装前先把口径写成配置而不是代码：巡检覆盖率等于正常完成项数除以应检项数，跳过算未覆盖，异常算完成；故障分级按工单创建时的级别字段；处理时长从接单到验证通过。口径配置化之后，规则调整不再改代码，负责人如果提出新的统计口径，改配置、下次生效，历史周报不追溯。口径管理是报表自动化的暗线，谁掌握口径定义权，谁就掌握报表的话语权。

3.2 聚合查询

周报主体是一条聚合查询，按固定窗口拉三张表的汇总数：

SELECT p.plan_name,
       COUNT(*) AS total,
       SUM(p.result = 1) AS ok_cnt,
       SUM(p.result = 2) AS abnormal_cnt,
       ROUND(SUM(p.result IN (1,2)) / COUNT(*) * 100, 1) AS cover_rate
FROM patrol_exec p
WHERE p.exec_time BETWEEN @win_start AND @win_end
GROUP BY p.plan_id;

工单表和状态日志各一条类似查询，三个结果集汇进报告模板。模板分四栏：巡检概况、故障与处理、设备动态、下周关注，最后一栏是留给值班长手写的，系统只负责数字，判断和计划还是人的事。自动化的边界画在这里：机器管事实，人管观点，周报才不至于是废纸。

3.3 定时任务与送达

每周五中午十二点的定时任务执行生成，产出网页版存档加邮件送达。送达名单做成了配置，负责人换人时改配置不改任务。生成后先发一封到运维组内部群预览十分钟，无异议再外发——这个缓冲十分钟救过一次场：某次窗口参数被误改，预览时数字明显异常，拦在了外发之前。自动化流程要给自己留检查点，全自动不等于全放心，流程跑得越顺，人越要留一个抬头看的动作。

四、运行一年后的账

这套周报跑了一年，粗算一笔账：每周节省三个人各半天，一年按五十周算是七十五个人日；更值钱的是口径统一后，负责人不再逐个核对数字，周报会从质询会变成了讨论会。另外积累下来的周报存档成了意外的资产：年度总结时按季度回看覆盖率曲线和故障分布，趋势一目了然，去年的年度设备分析报告，素材几乎全部来自这些周报的沉淀。报表自动化的回报，时间越长越明显，头一周省下的是半天，一年后攒下的是一整套可以回溯的数据资产。

五、总结

巡检周报自动化的路径：事实层三张表各管一段——执行、工单、状态变化，只记事实不下结论；口径层配置化，规则可调可追溯；拼装层定时任务加模板，机器出数字，人出判断。技术上没有难点，难点是说服自己花时间把口径写清楚——一旦口径落定，周报就只是一条聚合查询的事。反过来说，任何报表自动化的失败，栽的都不是技术，是没人愿意先坐下来把口径谈拢。

常见问题

问:负责人总要求改报表格式,自动化跟不上怎么办?

答:把格式和口径拆开对待。口径进配置,格式进模板,两者都做成可调整的。模板里变量占位,负责人要加一栏,提供数据源就插一个变量块,十分钟的事。真正不能随便动的是事实表结构——守住事实层,上层怎么折腾都是安全的;事实层被报表需求牵着改,系统迟早失去稳定性。

问:跳过的巡检项算不算覆盖率,口径怎么定?

答:没有标准答案,但必须有且只有一个答案,并且写进口径配置里。我们的选择是跳过算未覆盖,理由是跳过意味着该做的检查没有发生,风险敞口是真实的。有的团队把带原因的跳过算作覆盖,也说得通。关键不在选哪个,而在全公司只有一个算法,周报月报年报同源同口径,数字才能跨期比较。

问:周报数字和月报对不上是为什么?

答:九成是窗口边界问题:周报按周五正午切,月报按自然月切,交叉周的数据归属不同,合计自然有出入。解法是在报表脚注里固化窗口定义,并在月报里用日历窗口重新拉数,而不是简单加总四周周报。报表数字的可信,来自每个数字都带着明确的窗口和口径声明,而不是来自精确到小数点的表象。

问:数据源头质量差,报表出来的数字还是不准怎么办?

答:自动化解决的是搬运和拼装,不解决录入质量。先上基本的源头治理:必填校验、枚举值约束、执行人和时间从系统取而不是手填。再在报表层做合理性检查:覆盖率超过满格、工单量为零这类异常值先标黄再展示,提示数据可疑。源头脏数据是慢性病,报表层的合理性检查是体检指标,两件事都要持续做。