到目前为止我一直在谈产品能力是需要有价值输出能力和可复用能力，今天则重点考虑下另外一个重点即运维支撑能力。
我们现在的项目实施存在两个很弱的环节，也可以说是很不专业的环节，就是缺少一个可以对业务数据采集和业务模型运行进行配置管理、运行监控的系统。项目上进行数据采集和模型运行需要需要开发人员在代码中修改配置、然后登录服务器进行部署。如果没有详细的文档说明换一个人就很容易无所适从。即便有文档，我们的技术人员需要具备windiw和Linux服务环境的应用能力，这无形中提高了运维的门槛，离开了研发人员，这块得事情就干不了。另外一个突出的问题是，我们经常是要在客户使用系统的时候才意识到我们某项数据没有采集入库、我们的某个模型没有输出、我们某了接口无法被调用。这个时候只有参与开发的技术人员才能定位问题，然后进行一系列复杂的操作去定位问题并恢复。所以在产品即将面临大范围推广的阶段，我们提出开发能够支撑项目快速和持续交付的业务调度系统，而可配置、可监控则是这套系统的核心目标。
我们进一步分解需求。通常来讲我们有两大类任务，
一类是数据的采集，这块功能基本ETL差不多。具备支撑跨库数据同步、接口定时调用、FTP同步等，对于复杂的数据采集过程，我们能够支撑调用外部程序，比如直接调用JAR包或者执行python脚本来实现，这类方式最重要是对程序运行状态和日志的捕获，能够在程序出现问题后及时报警，并通过日志记录支撑问题定位。这也就要求系统设计之初需要考虑到可扩展程序调用方式，自己建立一套统一的状态监控和日志输出标准，所有采集程序必须基于这套标准来编写。
另外一类是模型的调度。这里我们把所有那些需要通过后台程序驱动去解决特定业务问题的统称为模型，所以简单到一个消息发送任务，复杂到一个内涝计算模型，我们都希望能够通过这个系统来进行配置管理和运行监控。听起来很复杂，但本质上就是用定时任务替代人为脚本控制程序运行。当然这块设计的关键依然是对状态和过程日志的监控，让我们对模型的运行时刻做到心中有数。所以，需要为所有模型地设计插入统一标准的运行状态和问题日志的能力。
通过可配置、可监控的运维调度提升快速交付、持续交付能力。
网友评论