class="topic_img" alt=""/>
对于很多团队来说，开发和运维现在还是两个世界的人，开发人员写着属于自己的代码，然后丢给运维人员。但作为开发人员，我们必须知道，运维的方式对于开发上的抉择是有影响的。
和这个世界上的许多项目一样，我现在正在开发的项目也有一些后台定时运行的任务。这是一个 Java 应用，但我并不想把这些定时任务扔进 Java EE 容器里，没有必要让这些后台应用和前台应用抢资源。所以，我们就把它做成了一个独立的应用。好，问题来了，谁来做定时调度？
因为我们的应用最终会部署在 Linux 操作系统上，所以，我的第一个直觉就是采用 Cron。这是一个已经存在了几十年的解决方案，没有任何问题，而且，开发团队几乎不需要做任何额外工作。这个方案一直存在到我们和运维团队交流为止。
“我们不允许使用任何系统任务”，运维团队开门见山地否决了我们的解决方案。运维团队给出的理由是，他们无法保证一台机器上只运行一个应用，如果其中一个应用挂了，运维人员也许会清理一些资源，换句话说，如果你的应用用了这些东西，也许会被一不小心地删掉了。“所以，按照我们规定，每个应用只能开辟自己的目录，运用自己目录下东西。”
这是一个合理的要求，所以，我们需要调整自己的设计方案，把原来交由系统处理的调度转成由自己的应用处理。当然，在 Java 世界，这不是太大的难度，Quartz 框架很好地帮我们处理了这些。
其实，与调度方案同时被推翻的还有我的另外一个方案。这次我原本想尝试把我们的日志写到系统日志里。如果你不知道的话，rsyslog 可以让我们把自己的日志写到/var/log 下。很显然，这样的方案在这样约束下也是不行的。我们只好回到 Java 的传统方式上，把日志写到自己的目录下。
这是两个由运维反过来影响开发方案的小例子。运维是开发的一种很重要的组成部分，运维团队的一些工作方式直接影响到开发上的一些决策。所以，如果开发和运维还是两个团队，开发团队不妨多找运维团队聊聊，更多地了解关于部署的方方面面。当然，更好的解决方案是走向通往 DevOps 的康庄大道。
相关文章
