A short example of working with known errors
A known issue in ITIL is an issue that has already been analyzed but has not yet been resolved.
How do known errors work and why are they needed? I'll show you in between.
Let us have an abstract IT service, in which development is in one department and operation in another. For example this:
Let us several hundred information systems and one 24/7 shift administrator. Who cannot know the intricacies of all systems. Let us have a distance learning system created by the development department.
Let's say that at the stage of creating a software product, the developer discovered that he sometimes connections to the database are not closed. It takes a long time to fix, but the application is already buggy. In this case, the developer registers a known error, something like this.
This is information for the shift administrator who monitors several hundred information systems You can quickly understand what to do if everything freezes, for example. In a simple way, we came up with instructions for a shift administrator who does not need to know anything about connection problems in Java,
Administrator responsible for operation registers a problem to monitor its resolution. It is important that the developers solve the problem, controlled the vertical operation. The problem has this simplified form:
See, it contains our known bug: “Java/Problem of storing and distributing Connection Pool for temporary use”! The problem is marked as database related, it is easy for the operating director to isolate this class problems and “present” them to the executive director, who is responsible for organizing the operation of this system.
Executive Director in response “will push” development department. And initiates system modification:
The post is as short as possible, written during the work process, while evaluating the functionality of elma365 (I have conflicting feelings, maybe I’ll write a review). I. This is an example of how to organize the process and minimize manual control.