Browse Prior Art Database

File Usage Metrics for Problem Determination Analytics

IP.com Disclosure Number: IPCOM000219747D
Publication Date: 2012-Jul-10
Document File: 4 page(s) / 48K

Publishing Venue

The IP.com Prior Art Database

Abstract

Described is a system which tracks debugging activities, including interactions with tools and artifacts, such that those activities are retained as part of a problem report as it is passed between investigators. This will allow investigators to see what has already been done, which will allow them to focus on areas that have not been investigated before or to continue in previously investigated areas without having to repeat activities done by previous investigators.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 01 of 4

Most IT companies provide Problem Management Reporting (PMR) services for their customers. The bug fixing process is not trivial. Usually, the customer help desk staff takes a customer's PMR and transcribes it into the system to start the process. Depending on the type and severity
of the PMR, sometimes the request will be passed to level 2 (L2) or level 3 (L3) engineers for further investigation. Often times, these L2 and L3 teams pass the bug between their internal respective teams (the kernal team transfers it to the IO team, or to the install or config team, etc.).

    In addition to problems caused by being collaborated on by multiple teams, there are often problem related artifacts (like trace files, log files, config files) which team members used to diagnose the problem or to determine where to transfer the problem.

    When these teams pass bugs around, team members (humans) attempt to describe the reasons for the transfer. Often what is missing from the description is exactly what the previous team member actually did and not what they think or remember doing. Some common questions could be:

Did they look at the trace?


Where in the trace did they look?

What were they searching for (what trail or scent were they on)


What did they highlight (people tend to highlight what they are looking at with the cursor)


What did they copy/paste (if they put snippets of a trace in a PMR, but they have multiple

traces or multiple entries, you can determine where they copied from)

    In today's enterprise business culture, where teams are spread across multiple geographies, multiple cultures, and multiple primary languages, there is a need to enhance the problem transfer information to understand what a person did. It is no longer simple to just ask someone down the hall or even instant message someone in another city or state given the global businesses of the 21st century. This problem requires enhancements to the bug fixing process and collaboration among multiple teams with different expertise and focused areas.

    Proposed here is a means to track the portions of the trace files that have been viewed/investigated by different engineers who are involved in the debug and fix process no matter what technology (Firefox* plugin, enhancement to any editors or text viewers) they are using. This capability can be an enhancement in an IDE environment. An IDE is an integrated software development environment where developers can design, develop, and test software applications. Proposed is to include tracking capabilities to capture the activities performed by engineers who handle the bugs/defects. For example, if Level 2 support engineer has spent one hour tracing the output of a particular servlet of the back-end or has been searching for certain parameters from the configuration file, the system can record their actions so that the Level 3 support engineer can know what the Level 2 has done in the debugging process.

    Proposed here is tracking users and the...