Let’s learn more about KEDB or Known Error Database, with the help of real life IT examples from a wide spread of different experiences. Most frequently the secret to success is engaging small problems each one at a time, rather than a single jump ahead. This means that is best to take one step at a time but for that you will need knowledge to be stored and improved upon, so one specific tool that helps organizations achieve this success is the KEDB or Known Error Database.
What is the Known Error Database?
To understand Known Error Database or KEDB anyone should know that there are three ITIL terms that you should be familiar with such as incident, problem and known error. What could be tagged as incident? Simple, if your email service goes down without notice from your provider, could be tagged as an incident. In this example, the reason behind the email outage is the problem, so a problem is the underlying cause of an incident. In other words, this is the thing that caused the issue in the first place.
Furthermore, we can say that there is no longer a problem, but a known error. Why is that? Because for the email issue, the root cause is identified as one of the critical services on the email server, so what use to be a problem now is known as an error.
Why is KEDB needed?
Now returning to the email problem, we can say that the critical services was in hung mode after running several diagnostics and undertaking some tests. After finding the problem, the resolution might have been faster where the service was stopped and restarted. The email service was down while the diagnostics and resolution were being applied and could result to penalties imposed by customers. So, if the email service fails again, the tech team will refer to the previous outage in the KEDB being able to start diagnosis with the service that caused the issue last time.
Anyway the company that offers e-mail services to its clients maintains a KEDB and be sure that this particular problem was recorded. If the email issue happens again, the tech support team can refer to the last outage in the KEDB and run a diagnosis with the service that caused the issue last time. At this point resolution might take a few seconds if it happens to be the same service causing the issue. With KEDB in place organizations are efficiently allocating money towards improving services.
Permanent solution and workaround
There are few ways for restoring service outages. The most ideal one, is a permanent solution, which entails a fix that guarantees zero outages. The most common type is the workaround that looks for an alternate solution. This second way is most frequently followed for implementing another solution at a later date. Restarting the service is a workaround in the email service outage. But this is probably to happen in the future and the tech support team knows that this will only solve the problem for the moment.
Now let’s see some aspects of KEDB in action.
Having seen what Known Error Database is, let’s understand how and when it gets recorded, used and maintained.
1. If an incident is resolved using temporary means, a known error is created with the incident summary, description, symptoms and all the steps involved in solving it.
2. If an incident appears the support team refers to the KEDB first to check if a workaround exists in the database.
3. There is a third possibility where a permanent solution to a known error is identified and implemented, the incident is not supposed to happen any more.
For maintenance and support services check our dedicated development specialists.
