一种IT运维风险预警方法

技术领域

本发明涉及网络运维风险技术领域，尤指一种IT运维风险预警方法。

背景技术

企业中IT(信息技术)的基础设施的数量不断增加，海量的运维和业务数据以这些IT基础设施为硬件基础，进行保存。可以想到的是，当企业的IT的基础设施出现故障时，对企业的安全生产和管理造成巨大的影响。因此，对于各种组织中的IT运维情况需要进行相应的风险分析，当面对运维问题时有备无患。 但是，现有技术通常使用的IT运维管控，只偏向于事件管理的被动式管控，也就是只有当故障事件发生，或故障相关事件发生后才对对应的故障进行管控，对于故障的风险无法做到很好的预识别，难于识别故障先发的征兆，进而无法采取有效的预防处理措施消除风险。

发明内容

鉴于以上问题，本发明提供一种IT运维风险预警方法来解决上述背景技术中提出的问题。具体如下： 为达到上述目的，本发明采用如下技术方案：一种IT运维风险预警方法，包括以下步骤： （1）数据收集：数据库分为三种类型，第一种是日志审计数据库，用于记录用户信息、策略信息和连接会话的日志信息等内容，第二种是文件数据库，专门用于记录应用代理服务器所记录每个连接会话的录像信息，录像信息与日志信息直接关联，直接通过查询日志信息后播放对应的录像文件，真实再现当时的操作画面，第三种是本用户系统以及其他用户系统出现过的故障数据。 （2）监控预警：对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。 出现疑似故障时，系统发送告警提示，提示方法包括短信、email、窗口弹出和声音报警。 （3）故障定位：管理员通过短信内容看到系统-应用-模块出现的具体问题。 （4）故障自愈：根据数据库的信息查找已有方法，自行解决。 （5）问题根源：根据以下五个定位故障问题寻找原因 A、是否为偶发性、是否可重现 故障现象是否可以重现，对于快速解决问题很重要，能重现的故障可以从服务异常、变更等工作方面查找原因。 B、是否进行过相关变更 大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。 C、是否可缩小范围 一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，先把问题范围缩小到一定程序后再开始协调关联团队排查。 D、是否有足够的日志 定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。 E、是否有core或dump等文件 故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如CORE\DUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。 （6）问题整改：根据已有问题和出现的疑似问题查找原因并解决后，上传分享故障。 本发明具有以下有益效果： 1.本系统可对所有用户进行集中管理，包括本地管理用户及远程管理的用户，可以通过本系统行使如下功能：用户的创建、修改、删除和查询、用户的启用和挂起控制、用户的权限管理功能。 2、出现疑似故障时，系统发送告警提示，提示方法包括短信、email、窗口弹出和声音报警，不放过任何一个可能存在的隐患。 3、在数据收集中包括本用户系统以及其他用户系统出现过的故障数据，而且在问题整改步骤中，根据已有问题和出现的疑似问题查找原因并解决后，上传分享故障，便于提前预警其他用户出现相似问题。

附图说明

图1为本发明方法流程示意图。

具体实施方式

为使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合，进一步阐述本发明。 在本发明的描述中，需要说明的是，术语“上”、“下”、“内”、“外”“前端”、“后端”、“两端”、“一端”、“另一端”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。 在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“设置有”、“连接”等，应做广义理解，例如“连接”，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。 请参阅图1，本发明提供的一种IT运维风险预警方法，包括以下步骤： （1）数据收集：数据库分为三种类型，第一种是日志审计数据库，用于记录用户信息、策略信息和连接会话的日志信息等内容，第二种是文件数据库，专门用于记录应用代理服务器所记录每个连接会话的录像信息，录像信息与日志信息直接关联，直接通过查询日志信息后播放对应的录像文件，真实再现当时的操作画面，第三种是本用户系统以及其他用户系统出现过的故障数据。 （2）监控预警：对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理。在监控工作中，不仅需要有服务进程、端口等监控，还需要有业务、交易层的监控。全面性的应用监控可以让故障提前预警，并保存了影响应用运行环境的数据，以缩短故障处理时间。 出现疑似故障时，系统发送告警提示，提示方法包括短信、email、窗口弹出和声音报警。 （3）故障定位：管理员通过短信内容看到系统-应用-模块出现的具体问题。 （4）故障自愈：根据数据库的信息查找已有方法，自行解决。 （5）问题根源：根据以下五个定位故障问题寻找原因 A、是否为偶发性、是否可重现 故障现象是否可以重现，对于快速解决问题很重要，能重现的故障可以从服务异常、变更等工作方面查找原因。 B、是否进行过相关变更 大部份故障是由于变更导致，确定故障现象后，如果有应的变更，有助于从变更角度出现分析是否是变更引起，进而快速定位故障并准备好回切等应急方案。 C、是否可缩小范围 一方面应用系统提倡解耦，一支交易会流经不同的应用系统及模块；另一方面，故障可能由于应用、系统软件、硬件、网络等环节的问题。在排查故障原因时应该避免全面性的排查，先把问题范围缩小到一定程序后再开始协调关联团队排查。 D、是否有足够的日志 定位故障原因，最常用的方法就是分析应用日志，对运维人员不仅需要知道业务功能对应哪个服务进程，还要知道这个服务进程对应的哪些应用日志，并具备一些简单的应用日志异常错误的判断能力。 E、是否有core或dump等文件 故障期间的系统现场很重要，这个在故障应急前建议在有条件的情况下留下系统现场的文件，比如CORE\DUMP，或TRACE采集信息等，备份好一些可能被覆盖的日志等。 （6）问题整改：根据已有问题和出现的疑似问题查找原因并解决后，上传分享故障，便于提前预警其他用户出现相似问题。 以上的仅是本发明的实施例，方案中公知的具体结构及特性等常识在此未作过多描述。对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。