[发明专利]问题检测系统

说明书

一种系统和方法包括监测一个或多个软件应用以确定与第一过程的实例相关联的第一指标的值，所述第一过程包括由所述一个或多个软件应用执行的步骤；确定在所述第一过程的第一数量的正在进行的实例中所述第一指标的值已经超过与所述第一过程相关联的阈值；确定所述第一数量大于与所述第一过程相关联的第一计数限制；并且响应于确定所述第一数量大于所述第一计数限制，向与所述第一过程的每个正在进行的实例相关联的用户发送错误消息。

背景技术

企业计算系统促进企业内许多过程的执行。尽管尽了最大努力，但潜在的技术问题可能会延迟或阻止此类过程的完成。技术问题可能存在于不同的计算系统中，并且可能是零星的或否则难以由负责的技术支持团队监测和/或检测。

当过程被延迟、停滞或以其他方式表现不佳时，受影响的用户(例如，启动过程的用户)创建支持工单并将其提交给技术支持团队。第二用户稍后可能会启动相同的过程并最终注意到所述过程未正确执行，从而导致第二用户创建并提交另一个支持工单。支持工单由支持团队排队，并且通知用户有关其相应工单的持续状态。

如果过程的问题是由于一个或多个潜在的技术问题(例如，网络连接故障)，许多用户将受到影响并且将创建许多支持工单。大量的工单可能会使技术支持团队不堪重负，他们将在尝试识别和解决问题的同时继续接收和排队新的工单。同时，整体用户满意度下降。

在一个实例中，公司允许其员工提交他们日常工作所需的商品和服务的采购请求。购买任何超过一定价值的物品必须由创建对应采购请求的员工的管理者批准。由于最近的配置更改，基于组织数据确定员工的管理者的规则开始出现故障。所述规则不会确定管理者，而是返回空的结果集。因此，不会发送任何批准请求，并且所有采购请求都未得到批准。

由于判定规则继续返回技术上有效的结果，因此没有检测到技术问题。过程监测解决方案可能会检测到采购请求批准的平均处理时间的增加，但这种检测对于检测或触发潜在技术问题的解决并不是特别有帮助。因此，只有在多名员工独立注意到异常延迟、与他们的管理者核实、询问其他同事是否有同样的问题并最终创建支持工单时，才会检测到问题。

希望系统能够有效且主动地识别干扰操作过程的技术问题并通知受影响的用户，同时限制错误的通知。

附图说明

图1是根据一些实施例的通过监测应用层来检测和解决技术层中的潜在问题的架构的框图。

图2包括根据一些实施例的通过监测应用层来检测和解决技术层中的潜在问题的过程的流程图。

图3至图7展示了根据一些实施例的随着时间的推移对应用过程的监测和用户通知的发布。

图8展示了根据一些实施例的用于应用监测的指标阈值的设置。

图9是根据一些实施例的通过监测应用层并基于用户工作时间来检测和解决技术层中的潜在问题的架构的框图。

图10是根据一些实施例的硬件系统的框图。

具体实施方式

提供以下描述以使本领域的任何人都能够制作和使用所描述的实施例，并提出了为执行一些实施例而设想的最佳模式。然而，各种修改对于本领域技术人员来说将是显而易见的。

实施例可以减少检测导致操作过程延迟或失败的技术问题的时间和精力。通过加速对此类技术问题的检测，可以比现有系统更快地触发相关联的通知和解决过程。

实施例可以检测问题并且作为响应启动解决过程并且在用户手动创建一堆支持工单之前主动通知用户。此类特征不仅减少了检测问题所涉及的用户开销并且加快了问题的解决，而且还向支持人员提供了快速的指示，即问题不仅与一个用户特定的过程有关，而且可能更为根本，因为它同样会影响多个用户和过程。