Close event

Review actions

With thousands of events being generated every day, it is not possible formally to review every individual event. However, it is important to check that any significant events or exceptions have been handled appropriately, or to track trends or counts of event types, etc. In many cases this can be done automatically, for example polling a server that had been rebooted using an automated script to see that it is functioning correctly.

In the cases where events have initiated an incident, problem and/or change, the Action Review should not duplicate any reviews that have been done as part of those processes. Rather, the intention is to ensure that the handover between the Event Management process and other processes took place as designed and that the expected action did indeed take place. This will ensure that incidents, problems or changes originating within Operations Management do not get lost between the teams or departments.

The Review will also be used as input into continual improvement and the evaluation and audit of the Event Management process.

Some event s will remain open until a certain action takes place, for example an event that is linked to an open incident. However, most events are not ‘opened’ or ‘ closed ’.

Informational events are simply logged and then used as input to other processes, such as Backup and Storage Management. Auto-response events will typically be closed by the generation of a second event. For example, a device generates an event and is rebooted through auto response – as soon as that device is successfully back online, it generates an event that effectively closes the loop and clears the first event.

It is sometimes very difficult to relate the open event and the close notifications as they are in different formats. It is optimal that devices in the infrastructure produce ‘open’ and ‘close’ events in the same format and specify the change of status. This allows the correlation step in the process to easily match open and close notifications.

In the case of events that generated an incident, problem or change, these should be formally closed with a link to the appropriate record from the other process.

4.1.6 Triggers, input and output/inter-process interfaces

Event Management can be initiated by any type of occurrence. The key is to define which of these occurrences is significant and which need to be acted upon. Triggers include:

• Exceptions to any level of CI performance defined in the design specification s, OLAs or SOPs
• Exceptions to an automated procedure or process, e.g. a routine change that has been assigned to a build team has not been completed in time
• An exception within a business process that is being monitored by Event Management
• The completion of an automated task or job
• A status change in a device or database record
• Access of an application or database by a user or automated procedure or job
• A situation where a device, database or application, etc. has reached a predefined threshold of performance.

Event Management can interface to any process that requires monitoring and control, especially those that do not require real-time monitoring, but which do require some form of intervention following an event or group of events. Examples of interfaces with other processes include:

• Interface with business applications and/or business processes to allow potentially significant business events to be detected and acted upon (e.g. a business application reports abnormal activity on a customer ’s account that may indicate some sort of fraud or security breach).
• The primary ITSM relationship s are with Incident, Problem and Change Management. These interfaces are described in some detail in paragraph 4.1.5.8.
• Capacity and Availability Management are critical in defining what event s are significant, what appropriate threshold s should be and how to respond to them. In return, Event Management will improve the performance and availability of services by responding to events when they occur and by reporting on actual events and patterns of events to determine (by comparison with SLA targets and KPIs) if there is some aspect of the infrastructure design or operation that can be improved.
• Configuration Management is able to use events to determine the current status of any CI in the infrastructure. Comparing events with the authorized baseline s in the Configuration Management System (CMS) will help to determine whether there is unauthorized Change activity taking place in the organization (see Service Transition publication).
• Asset Management (covered in more detail in the Service Design and Transition publications) can use Event Management to determine the lifecycle status of asset s. For example, an event could be generated to signal that a new asset has been successfully configured and is now operational.
• Events can be a rich source of information that can be processed for inclusion in Knowledge Management system s. For example, patterns of performance can be correlated with business activity and used as input into future design and strategy decisions.
• Event Management can play an important role in ensuring that potential impact on SLAs is detected early and any failure s are rectified as soon as possible so that impact on service targets is minimized.

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