对于互联网产品或长期运行的产品而言，运维工作非常重要，尤其是在产品复杂了以后，在这篇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的运行方式这种发布方法就没法玩了）。
经过这个阶段的折腾，就积累了两个脚本，一个用来发布应用包，一个用来发布页面。

每次发布应用包的时候都会有短暂的不可用，这样总折腾下去用户受不了（如果哪天这唯一的一台服务器挂掉的话，就更糟糕了），