[[111441]]

對于很多團隊來說，開發和運維現在還是兩個世界的人，開發人員寫著屬于自己的代碼，然后丟給運維人員。但作為開發人員，我們必須知道，運維的方式對于開發上的抉擇是有影響的。

和這個世界上的許多項目一樣，我現在正在開發的項目也有一些后臺定時運行的任務。這是一個Java應用，但我并不想把這些定時任務扔進Java EE容器里，沒有必要讓這些后臺應用和前臺應用搶資源。所以，我們就把它做成了一個獨立的應用。好，問題來了，誰來做定時調度？

因為我們的應用最終會部署在Linux操作系統上，所以，我的***個直覺就是采用Cron。這是一個已經存在了幾十年的解決方案，沒有任何問題，而且，開發團隊幾乎不需要做任何額外工作。這個方案一直存在到我們和運維團隊交流為止。

“我們不允許使用任何系統任務”，運維團隊開門見山地否決了我們的解決方案。運維團隊給出的理由是，他們無法保證一臺機器上只運行一個應用，如果其中一個應用掛了，運維人員也許會清理一些資源，換句話說，如果你的應用用了這些東西，也許會被一不小心地刪掉了。“所以，按照我們規定，每個應用只能開辟自己的目錄，運用自己目錄下東西。”

這是一個合理的要求，所以，我們需要調整自己的設計方案，把原來交由系統處理的調度轉成由自己的應用處理。當然，在Java世界，這不是太大的難度，Quartz框架很好地幫我們處理了這些。

其實，與調度方案同時被推翻的還有我的另外一個方案。這次我原本想嘗試把我們的日志寫到系統日志里。如果你不知道的話，rsyslog可以讓我們把自己的日志寫到/var/log下。很顯然，這樣的方案在這樣約束下也是不行的。我們只好回到Java的傳統方式上，把日志寫到自己的目錄下。

這是兩個由運維反過來影響開發方案的小例子。運維是開發的一種很重要的組成部分，運維團隊的一些工作方式直接影響到開發上的一些決策。所以，如果開發和運維還是兩個團隊，開發團隊不妨多找運維團隊聊聊，更多地了解關于部署的方方面面。當然，更好的解決方案是走向通往DevOps的康莊大道。