例会七点开、七点半散，到场的三个人手里拿的还是前一天的日报，当天那张要到凌晨四点才生成。会前只来得及翻前两页，第三页以后的异常没人看。散会后要盯的那几页异常，只能等第二天再看，该处理的那件事已经过了当天。票务系统里日报生成的那个时刻，本身就是一项该被排的任务，不是顺手设下的默认值。

任务时刻分三层，一层一层看。第一层是数据写进系统，夜场的核销、退款的回写、团体票的确认都压在这一层，售票系统的明细表就是这层的产物。第二层是汇总跑批，日报生成靠它把明细算成指标。第三层是推送给谁，跑完自动发给当天的值班经理和财务对账的人。三层各有一个时刻，只有第二层的时刻能由人定，前两层受现场进度牵着。

跑批起点定在 02:00，先核写入完成率

凌晨四点晚在不赶七点的会，日报生成往后挪，会前能看的还是那两页。把跑批起点定在 02:00，中间留出两小时容错，即使重跑一轮也赶在开会前。起点不是随便提的，前置条件是当日核销数据写入完成率到 95% 以上，不到这条线就不许起批。这条线写进票务系统的任务配置里，不靠人记。两小时容错不是给拖延留的余地，是给重试和报警留的。

挪早了数会不会不全，取决于上游写完没有。闸机的夜场核销要时间回写，自助售取票机的退款回写也要时间，售票系统里夜场票的明细同样压着没进。01:00 起批看着提前三小时，缺的那一截第二天得手工补。上游没写完，跑批就等，等到写入完成率过 95% 再起。当场能做的检查：在任务日志里看写入完成率这一栏，拿它和 95% 比，低于这条线就算这次起批太早。等的时候报表页保持上一版，不出半张表。

票务系统的日报任务，超 06:00 未出就报警

跑批失败自动重试 3 次，每次间隔 10 分钟，三次都不成才报警。超过 06:00 仍未出表，这一次日报生成算延迟，报警直接推给当天值班的人。报警要带上写入完成率到了多少、缺哪一类数据，值班的人一屏就能定位。表出来后第一个看它的是值班经理，第二个是财务对账的人，运营负责人只收异常提醒，不逐页翻。

两种排法各走一遍，差别在第二天就露出来。一种把跑批定在 01:00，图早，结果夜场核销只写了九成，不到七点就得手工补数，售票系统的明细和日报的指标对不回去。另一种按 02:00 起批，日报生成比前者晚一小时，但一次跑全，票务系统里核销、退款、团体票三样都齐了才交表。早与晚的取舍，看的是完成率那条线。

只有在跨零点那场演出的时候，归日不受跑批时刻影响。这一类场次按场次归日，开场落在哪天就进哪天的表，02:00 起跑批也照样把它算进开场那天。夜场散场晚、数据写回慢，不能为它把日报生成的起点往后推。这场该进哪天由场次定，不由跑批定。