當開發遇到運維

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

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

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

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

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

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

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