从运维的角度看批量设计

批量问题1：
最近支付系统因为晚收到了人行的清算文件，导致清算跑批失败，下游个人业务和对公业务没有及时收到支付系统清算结果文件，对账不平，需要手工调账，加上需要老板邮件批复才可以手工调账，占用了大家特别多的时间。

问题
1. 文件没有取到没有及时告警：只是简单去清算机构取全量文件，没有对具体文件监控
2. 跑批失败时没有及时告警：批量程序本身没有触发告警，而是在外部启动线程每小时定点监控任务状态发告警，延迟厉害
3. 有时候，文件在我们跑批时间后才生产，导致我们批量必然失败，没有办法人工干预

改进
1. 监控：对于时效性敏感的文件，结合文件的正常提供时间，增加单独的监控。比如：清算机构每日18：28前文件已提供，我们18：30检查文件是否存在，不存在马上告警，这样可以人工监控文件是否已生成，争取在跑批前人工获取好文件；
2. 批量程序及时告警：批量程序跑批失败时，调用告警接口，实时通知。该做法最好在批量程序第一次上线时就做，否则上线很久后再加入需要全量回归测试；
3. 针对批量文件在跑批时间后送达的情况，我们要做好预判，先暂停当天任务，等文件到达后再续做；同时要通知下游暂停他们的批量任务，避免跑批失败或者错过批量任务；


批量问题2：
某个批量任务平时只要跑不到1个小时，结果跑了2个小时都没有结束，也没有及时发现。问题发生后，开发人员不知道问题在哪，等着批量自然结束。

问题：
1. 没有监控：任务没有跑完，虽然没有报错，但是应该及时告警
2. 问题诊断：虽然批量框架能展示目前进行到哪个步骤，但是步骤里具体是因为什么原因一直不结束，不知道诊断

改进：
1. 需要监控每个批量产生的结果文件的正常生成时间，及时告警
2. 需要知道java性能诊断的基本方法，比如thread dump去分析目前程序到底在做什么，同时有配套的性能监控工具去监控系统潜在的性能问题多角度分析，比如我们使用了AppDynamic监控DB慢sql。

批量问题3：
某日核心系统需要提前一个小时跑批，需要上游系统提前跑批。

问题：在当天中午没有批量任务时，修改批量任务时间表，确保任务提前跑，特定任务前跑完后再修改回原来的跑批时间。主要问题是修改后需要重启程序。

改进：
批量框架应该支持实时修改任务配置，并时效生效， 不应该重启程序，以免影响其他任务。

总结

为了高效运维，批量设计需要从以下方面考虑：
1. 跑批失败告警
2. 监控上下游文件生成时间，没有按时生成需要告警，及时人工干预
3. 需要支持任务暂停和续做
4. 需要支持实时修改任务配置，无需重启程序