某日中午，有用户陆续反映系统问题，说流程送出异常、待办不消失、待办打不开等等。维护工程师开始分析问题，后台较为清晰的现象是流转日志记录插入数据失败，人工测试表插入成功，其它现象五花八门，没有规律，经过多位维护工程师的努力，终于由Oracle数据库管理工程师在16：01排除故障，系统基本恢复“正常”。

        故障原因是“应用系统Oracle数据库中Cordys用户所对应的表空间”满了，导致应用无法正常向数据库写入数据，造成业务数据不完整。

        第二日，维护人员根据用户反馈，逐个流程处理，并公告所有用户，在故障时间段内容发起、处理的业务如有异常，请尽量重新发起流程办理，尽管这样，维护人员的电话也打爆了。

        不幸的、担心的事情还是发生了，有用户反馈，新启动的流程有的也有异常！

        了解这些情况后，我建议维护负责人，把Cordys服务停了，重启Oracle数据库。当晚下班，维护人员就按此方案操作。第三日系统恢复正常，维护人员继续处理故障数据，维护工程师研究故障数据范围。

         经过上述过程，在规范IT运维管理环境下（分工明确：分一线、二线、三线人员及专业线分工），维护系统总结如下：

         1、在一个上线多年，而且没有改动的情况下，出现了无规律异常现象，基本上可以定位是应用软件以外的问题，例如数据库系统、操作系统等，做为直接面对用户的软件维护人员在上报的同时，及时建议联系应用软件以往的维护人员；

         2、对于此应用系统，如果出现表空间满了，出现数据写入故障时，特别是定位到是Cordys用户所对应的表空间满了的情况下，为了避免事态扩大，减少故障数据，需要立即做的工作如下：

         1）、停止应用服务；

         2）、处理数据库故障，例如扩表空间；

         3）、重启数据库；

         4）、启动应用服务（按重启处理）；

         5）、测试、验证系统是否正常。

        附：故障严重性说明

        如附图所示，这是相关性3天的数据，统计工作时间内，按每整点、半点统计汇总，此前间隔30分钟时段内的待办任务处理量，非人工节点、特殊情况未统计在内。统计最近1周的11点到16点间的流程业务操作频次为3000-3500笔之间（还好，避开了高峰点），因此可估算出大致的故障数据范围。