Event notification

Event occurs

Process activities, methods and techniques

Figure 4.1 The Event Management process

Figure 4.1 is a high-level and generic representation of Event Management. It should be used as a reference and definition point, rather than an actual Event Management flowchart. Each activity in this process is described below.

Event s occur continuously, but not all of them are detected or registered. It is therefore important that everybody involved in designing, developing, managing and supporting IT service s and the IT Infrastructure that they run on understands what types of event need to be detected.

This is discussed in paragraph 4.1.10.1, titled ‘Instrumentation’.

Most CIs are designed to communicate certain information about themselves in one of two ways:

• A device is interrogated by a management tool, which collects certain targeted data. This is often referred to as polling.
• The CI generates a notification when certain conditions are met. The ability to produce these notifications has to be designed and built into the CI, for example a programming hook inserted into an application.

Event notifications can be proprietary, in which case only the manufacturer’s management tools can be used to detect events. Most CIs, however generate Event notifications using an open standard such as SNMP (Simple Network Management Protocol).

Many CIs are configured to generate a standard set of events, based on the designer’s experience of what is required to operate the CI, with the ability to generate additional types of event by ‘turning on’ the relevant event generation mechanism. For other CI types, some form of ‘agent’ software will have to be installed in order to initiate the monitoring. Often this monitoring feature is free, but sometimes there is a cost to the licensing of the tool.

In an ideal world, the Service Design process should define which events need to be generated and then specify how this can be done for each type of CI. During Service Transition, the event generation options would be set and tested.

In many organizations, however, defining which events to generate is done by trial and error. System managers use the standard set of events as a starting point and then tune the CI over time, to include or exclude events as required. The problem with this approach is that it only takes into account the immediate needs of the staff managing the device and does not facilitate good planning or improvement. In addition, it makes it very difficult to monitor and manage the service over all devices and staff. One approach to combating this problem is to review the set of events as part of continual improvement activities.

A general principle of Event notification is that the more meaningful the data it contains and the more targeted the audience, the easier it is to make decisions about the event. Operators are often confronted by coded error messages and have no idea how to respond to them or what to do with them. Meaningful notification data and clearly defined role s and responsibilities need to be articulated and documented during Service Design and Service Transition (see also paragraph 4.1.10.1 on ‘Instrumentation’). If role s and responsibilities are not clearly defined, in a wide alert, no one knows who is doing what and this can lead to things being missed or duplicated efforts.

Дата добавления: 2014-12-23