In the first blog we identified that ConsoleWorks IEMs automatically capture log-file changes and scan them for vendor-defined error codes. This automation moved the MTTR detect process step from reactive failure with log trolling to real-time event detection. Now that real-time events are detected, the next step is the isolate those events that are real problems.
To do so, we need to understand the nature of the event codes that vendors have defined. These codes rarely tell us much about the problem, and they don’t tell us anything about their severity rating. That means we have to look up each code, see how important the vendor thinks it is (severity rating), and then see what they say about the actual problem the code represents.
Most event code patterns are alpha-numeric identifiers that have no real meaning to a human being, so the ConsoleWorks IEMs serve another purpose – encoding the severity rating along with the human-readable description of the event provided by the vendor.
In addition to real-time notification with no human intervention, the events are textually and visually called out by severity rating so at a glance we know what events signal real problems. Next to the severity rating is a description of the event so we also know how the vendor describes each event in human-readable form. The system automatically displays this information to the ConsoleWorks user – in milliseconds from the time the actual event occurred on the IT asset (hardware or software) eliminating all of the MTTR time typically used to ascertain what has happened. Now the time to isolate the real problem is gone, and whatever it used to be is a direct MTTR reduction. Besides Analyze and Remediate, we have effectively eliminated all of the other process steps that typically go into the process behind our MTTR number.
So now our MTTR impact is as follows: Detect = 0, Isolate = 0, Analyze = ? and Remediate = ?
Read Part 3 – ConsoleWorks Reduces Mean Time To Repair (MTTR) | ANALYZE – Part 3 of 4
