关于项目，有一个定义是：项目是创造独特产品、服务或其他成果的一次性工作任务。
项目并非实现产品经理的需求就完事了。 当项目投产后，在用户使用的过程中，会遇到千姿百态的问题。相当长的一段时间里，开发人员可能会疲于应付处理这样的问题。 运维一个应用系统不容易呀，那么，为什么会投入这么多时间呢？可能包括用户对业务逻辑的不够清楚，包括程序实现的bug，包括逻辑的复杂，包括线上运行过程中突发的事故。 而这些，往往并不在产品经理的需求范畴里， 所以，在系统实现方面，还应考虑应用系统的运维功能，包括：
监控
系统在运行过程中，难免会因为服务器问题或网络问题导致挂了， 所以，存活性监控是必不可少的。
业务监控：比如短信平台出现过被恶意攻击的情况，客户通过代理伪造了很多的手机号和IP最终触发了我们的短信通知。 像这种情况，应该做一个监控，如果某段时间里短信下发量突然暴增，就要告警并给予关注了。
我曾有一篇监控的文章《Promise计算模块验证和监控》。
当然，性能监控是更高阶的要求了，比如系统吞吐量（TPS）、TP99指标；服务器的disk io、cpu、memory、net io监控不在话题内，略过。
运营支持工具
以差旅订单通知系统为例，客户反映，说你系统出现问题了，你开始向客户索要相关信息，然后排查程序，写一大堆的sql，这样一来，个把小时过去了，你终于把客户的问题解决了。
再以审批系统为例，客服找你，说某个订单，客人手机出问题了无法通过短信审批，你帮忙改下订单的审批状态吧。你开始写sql，改审批单状态，改订单状态，然后，向领导申请，找运维人员在生产环境执行sql。然后，告知客服改好了，客服再告知客人。这样一来，估计快也得半小时。
初看起来，处理系统问题，不就是这么回事嘛。 作为一名项目管理者，我喜欢从成本和绩效的角度考虑，这种处理问题的方式，首先浪费了开发人员的时间，而且这种重复性的工作并不能产生多少业绩，所以一些程序员喜欢抱怨自己的工作无聊也不足为怪。其次呢，如果程序员手头又在参与新的项目，这会令他们无法专注于眼下的工作，事儿多容易乱。那么，我们就要想法对这样的工作say goodbye！ 运营支持工具就派上用场了，以上面的帮助客服修改订单审批状态为例，开发一个这样的工具，当客户再有这样的需求时，一个文本框一个按钮就搞定了（条件可以的话，把这个工具交给客服操作，我们程序员就解放了）。
从全局的角度看，这样也节省了客服的工作效率。她们会感谢你的。
运营手册
系统在使用过程中会出现各种你想不到的问题，
即使前期的需求做的多么完美（实际情况下，多数的产品设计出来的需求，在投产后，很多的问题是产品事先没有考虑到的）。
技术方面，用户异常输入致使字段类型长度不够、static的误用、内存的泄露、nullpointerexception。。。等等，无法避免。
不断的迭代，回归测试不足是常态，导致新功能满足了原有功能遭殃了。
好脑袋不如烂笔头。我们需要一个系统运营手册，以日历的形式记录日常出现的问题，常见的原因，解决方案，或者需业务上哪些人给予协助。 遇到过的技术问题和技术解决方案。同样，记录备忘性的内容，比如依赖的上下游系统的接口、联系人。
要说明的是，对于团队项目，这些文档要放到svn等版本管理工具里，大家共享共同更新。
温故而知新。运营手册不是整理完了就放那儿不管了，要定期review，对常见的运维内容，提炼出共性，作为新的需求来有针对性的进一步升级系统，如此以来，问题将会逐渐变少，并能hold住。
BTW，如果系统易主，这对于接管的团队来说，是非常宝贵的资源。
异常错误检测和补偿
一个定时跑批服务，可能会因为服务器异常，导致某次该跑但未跑。
一个批处理程序，可能因为某条记录的“非法”数据，导致漏掉了该条记录的处理。
涉及到完整的业务流程处理的，可能会因为事务得不到很好的控制，而导致数据不一致。 同样，对于分布式系统，数据不一致更常见。
以上情况，在系统运行过程中，我们一定会遇到。 我们要对系统的这些异常数据进行检测，检测是手段，检测不是目的，目的是要将数据调整过来，不一致的调成一致，缺失的数据想办法补充或直接废除。
通过以上方面的努力，我想，运维一个应用系统将会变得更容易！同时，我们得以解放出来，去专注于更多的工作。 拙文写的比较糙，还有更多更好的实践方案还需再积累，也期待和大家一起交流。
