[[111441]]

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

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

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

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

這是一個合理的要求，所以，我們需要調(diào)整自己的設(shè)計方案，把原來交由系統(tǒng)處理的調(diào)度轉(zhuǎn)成由自己的應(yīng)用處理。當然，在Java世界，這不是太大的難度，Quartz框架很好地幫我們處理了這些。

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

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