三、 运行维护的保障 

    如果从运维角度看IM建设，可以划分为如下几个层次： 

    •仅完成业务操作功能的，没有专门的监控环境建设。 

    •部署了技术领域运行监控的。 

    •提供了整体技术平台的集中式运行监控的。 

    •提供了基于业务影响程度分析的运行体系。 

    •确保IM自身持续可用基础上，IM自身作为业务优化和改进的环节，而不仅仅是作为业务之外的一个独立机制。 

    作为大型企业应用，起码要做到第三个层次，否则IM本身怎么做到令用户放心使用的程度？虽然现阶段主要的数据厂商都在向信息管理和内容管理过渡，并且在自己的产品线都提供了技术运维部分相对很全面的机制和产品，但如何切合业务领域，也就是如何从第三个台阶迈上第四个台阶，基本上都只停留在概念阶段。 

    倒是一些专门的运维产品在积极倡导相关概念并发布了一些不错的产品。作为大型企业应用的规划者，应用建设及配套的运维机制是否有严格的先后次序呢？笔者认为不仅不该分先后，而且必须同时进行（可用性要求非常高的项目，甚至要运维先行）。

图2：应用设计、开发（黑色）与运维设计、实施（灰色）的关系

    运维的目的虽然可以列举很多，但最重要的就是保证图1中那个逻辑的“泛”数据库总是可用。不过运维怎么知道IM是否真的健康呢？如果IM自己针插不进、水泼不进，恐怕也只能自己管自己了。但大型企业应用涉及的内容很多，依赖每个逻辑组成自治化的管理很容易造成运维失控的局面。 

    因此，设计大型IM的时候就要为运维留出通道，而且要把应用自身和数据源产品分工衔接好：应用要尽量提供业务能力的运维信息、数据源产品要提供详细的技术分析报告，最后通过“配置管理 + 业务影响分析建模”等手段，把两者有效地关联起来。目标如下： 

    “IM技术层面出了问题，除了IT可以知道外，可以换算为业务影响分析报告，通知业务部门和高层；IM业务层面感觉到了不适，除了可以及时通知上下游部门外，还可以由运维机制解析出技术层问题，通知到IT。” 

    不过考虑到企业IT队伍人员技术背景的关系，很难单纯依靠企业自己的IT实现上述目标，信息和内容管理产品厂商要把现有的运维支持提升，提供配置管理和尽可能方便的“业务影响分析”建模工具。