對於互聯網產品或長期運行的產品而言，運維工作非常重要，尤其是在產品復雜了以後，在這篇blog中就來說下Java應用的運維工作（ps：雖然看起來各種語言做的系統的運維工作都差不多，但細節上還是會有很多不同，so本文還是只講Java的）。
苦逼的碼農按照需求開發好了一個全新的Java Web應用，該發布上線給用戶用了，要把一個Java Web應用發布上線，首先需要搭建運行的環境，運行的環境需要有JDK、APPServer，在已經裝好了os的機器上裝上JDK和APPServer，開發好的Java Web應用可以用maven直接打成war或ear，將這個打好的包scp或其他方式到目標機器上，准備妥當，就差啟動了。
通常APPServer都帶有啟動腳本，在做好了上述准備後，直接運行啟動腳本，通常就OK了（maybe需要修改appserver的一些配置文件，例如修改監聽端口等）。
應用啟動後，有一個問題需要解決，就是如何確認應用啟動後成功與否，對於Java web應用通常可以放一個jsp文件，在這個文件裡做一些必要的檢查，以確保應用啟動是正常的，例如通常Java web應用會基於spring之類的框架來寫，為了確保spring的BeanFactory初始成功，可以在jsp文件裡去獲取下spring裡的bean調用下。
應用完成了啟動後，這個階段的工作就算完成了，這個階段完成後積累了一個應用啟動的腳本，用來啟動應用服務器以及在啟動完畢了後檢驗應用是否啟動成功。
只要不是一個一次性的應用，就必然會涉及修改的問題，修改完了後就得重新發布，對於Java Web應用，在修改完了後重新打應用的包，然後scp覆蓋到目標機器上，重啟，就可完成修改，但顯然，每次修改完代碼後都這麼操作實在是痛苦不堪，於是喜歡“偷懶”的同學會專門搞台發布用的機器（或者就是運行應用的那台機器），然後寫個腳本，每次需要發布時就通過腳本自動的將發布需要做的所有事情自動做好，:)，這下以後發布爽多了。
相應的這個時候通常還要支持回滾，即應用發布失敗後自動的回滾到前一版本的功能，也可以折騰到腳本裡。
但如果只是為了修改個頁面，就得這麼折騰，顯然還是麻煩了點（主要是經常重啟，用戶受不了），於是需要支持僅更新頁面的發布方式，為了支持這種方式，通常就要求打出的war/ear是解開了的，這樣才比較方便直接覆蓋頁面，繼續“偷懶”的本性，寫些腳本，支持將需要發布的頁面文件從svn或git下載，然後打成一個tgz或其他壓縮包，scp到目標服務器，解包覆蓋完成頁面的更新（當然，對於編譯jsp的運行方式這種發布方法就沒法玩了）。
經過這個階段的折騰，就積累了兩個腳本，一個用來發布應用包，一個用來發布頁面。
每次發布應用包的時候都會有短暫的不可用，這樣總折騰下去用戶受不了（如果哪天這唯一的一台服務器掛掉的話，就更糟糕了），於是就把應用的機器數從一台變成兩台，通常這裡對應用是有些技術要求的，這篇blog中只談運維，通常情況下從部署在一台變成兩台後，要做這些事：
1、可能會增加一台機器用來部署nginx/apache來做負載均衡，這個規模的情況下應該很少有會采用lb設備或lvs的（某些國企除外…），於是就得折騰下這台機器的環境等了；
2、增加了一台應用的機器後，就得又來搭建一次應用的運行環境了，通常這個時候“偷懶”的本性會發作，干脆折騰個腳本吧，來支持從另外一台運行的應用機器clone運行環境，做的更好點的話，就會把應用的運行環境記錄在某個地方、然後把應用運行需要的軟件也放在某個地方（例如yum），這樣，當要搭建應用的運行環境時，就可通過記錄的信息以及yum源等直接完成運行環境的搭建。
3、但這樣還沒完，為了避免發布的時候應用完全不能用，除了技術上要做的那點事外，在發布應用時就會多加一步，就是要先發一台，再發另外一台，由於之前有發布腳本，通常這也不是問題，:)。
經過這個階段，就又積累了兩個腳本，一個用來管理負載均衡的那台機器，另一個腳本用來搭建應用的運行環境。
隨著應用越來越受歡迎，通常應用的機器就得繼續加了，這個時候對運維工作又會帶來新的挑戰，主要還是在發布上，這個時候應用部署在了一堆的機器上了，每次發布的時候手工輸入一堆的機器地址來發布顯然很麻煩，於是需要有個地方來記錄應用有哪些機器（還記得我們之前搞了個地方來記錄應用的運行環境信息吧，可以放一起），除了要解決這個問題外，還需要解決的一個問題是這個時候通常對應用的發布方式會有了多種要求，例如分批發布（先發5台，再發10台，再全部發，或一半一半發等），更高級的話會有beta發布、灰度發布等要求，這個具體可以見facebook的大牛@魏小亮 寫的《代碼和產品發布的幾種方式》，這個時候顯然，之前寫的那個簡單的發布腳本就無法支持了，於是得搞個更為復雜的腳本來支持這多種的發布方式（有些還需要應用架構上做配合改造才能實現），做的更好的就是提供一個web版本的發布系統，來更為方便的進行發布以及發布過程的管理。
經過這個階段後，通常可以折騰出一個web版的應用運維系統了，包括應用信息的登記（依賴的運行環境、運行的機器地址）、應用的發布、頁面的發布、增加應用的機器、下線應用的機器。
通常繼續發展下去，會出現一些新的狀況，主要是會開始多元化，有了很多個應用，這個時候原來的web版應用運維系統就要支持多應用了，這裡主要會帶來的問題是為了降低運維的復雜性，需要做一些通用性的工作，例如通用的啟動腳本等，這個時候會產生一些要求，例如統一的應用名等，另外會帶來的問題就是開發、運維的人多了，這個時候權限上就需要有些控制了，例如某些賬號可以操作某些應用等，這個時候通常需要增加一套權限系統，集成到之前的運維系統。
應用多了後，還會帶來的問題是應用部署的規范性（同時也是為了降低運維的復雜性），因為每個應用可能都會有一些特殊的配置，這個時候最好是能夠通過搭建運行環境以及權限控制來保證一個應用部署後的目錄控制。
經過上面的一些發展過程後，Java應用的運維工作基本就可以比較自動的去完成了，但通常其實應用運維除了上面的工作外，還有一件更重要的事，就是保障應用的穩定，應用運維人員需要能夠排查大部分的應用故障問題，而不是交由後面的開發人員來解決，通常這個時候需要一套自動的故障處理系統，感興趣的同學可以參與下facebook的FBAR。
