IT has used monitoring tools for decades now to gain insight on how systems are operating. Usually tools would be purchased and then aspects of systems monitored based on what the tool could do and what the people implementing the tool knew about the system. As time went on, the tools evolved to trend data over time, generate alerts and alarms and send them via pages and emails and even trigger applications to execute predefined tasks. However, the processes that could leverage the tools didn’t keep pace.

A good deal of knowledge has built up over how to monitor certain systems (and now end-to-end services), but consistent manner to collect and apply knowledge in a relative short amount of time with high degree of success is lacking. This is a repeated theme we see in IT: technology-led approaches that deliver inconsistent results. Instead, what is needed is a process-led approach that not only delivers consistent results but can be evolved as well.

The Event Management process is a formal process that begins during Service Design and extends through Service Transition into Service Operation. It is tasked with the formal definition of events, including their identification criteria and the approved responses. It has a defined process owner and manager the same as other processes.

Finding the Needles

To level set, an event is a change in state. It could relate to hardware, software, people, facilities, environmentals, etc. For any data center, or IT organization overall, there is an unbelievably large number of events transpiring every second. Somewhere in that storm of events there are certain events that IT should know about. So, how do we find the proverbial needle in the haystack?

When we look at monitoring the IT landscape, what frequently happens is a new application is installed in a data center and operations then figures out how to monitor it. Even accepting some missteps and a sometimes steep learning curve, a complex system may not be monitored correctly for as long as a year. We need to shift the thinking to one of services and a service development lifecycle that takes all aspects of a service into account during development―including what events may happen and how to monitor for them.

With a properly designed and implemented Event Management process, the walls between development, test, and operations are broken down to allow for the understanding of the entire service that is being provided. Coupled with Service Asset and Configuration Management an understanding of the overall service is identified. This includes not just dependency/relationship data but also operating parameters, monitoring for known errors, and so on. Service level management (SLM) can provide input on negotiated service level objectives and so on. These processes are all interdependent and need to work together and share information.

IT has used monitoring tools for decades now to gain insight on how systems are operating. Usually tools would be purchased and then aspects of systems monitored based on what the tool could do and what the people implementing the tool knew about the system. As time went on, the tools evolved to trend data over time, generate alerts and alarms and send them via pages and emails and even trigger applications to execute predefined tasks. However, the processes that could leverage the tools didn’t keep pace.

A good deal of knowledge has built up over how to monitor certain systems (and now end-to-end services), but consistent manner to collect and apply knowledge in a relative short amount of time with high degree of success is lacking. This is a repeated theme we see in IT: technology-led approaches that deliver inconsistent results. Instead, what is needed is a process-led approach that not only delivers consistent results but can be evolved as well.

The Event Management process is a formal process that begins during Service Design and extends through Service Transition into Service Operation. It is tasked with the formal definition of events, including their identification criteria and the approved responses. It has a defined process owner and manager the same as other processes.

Finding the Needles

To level set, an event is a change in state. It could relate to hardware, software, people, facilities, environmentals, etc. For any data center, or IT organization overall, there is an unbelievably large number of events transpiring every second. Somewhere in that storm of events there are certain events that IT should know about. So, how do we find the proverbial needle in the haystack?

When we look at monitoring the IT landscape, what frequently happens is a new application is installed in a data center and operations then figures out how to monitor it. Even accepting some missteps and a sometimes steep learning curve, a complex system may not be monitored correctly for as long as a year. We need to shift the thinking to one of services and a service development lifecycle that takes all aspects of a service into account during development―including what events may happen and how to monitor for them.

With a properly designed and implemented Event Management process, the walls between development, test, and operations are broken down to allow for the understanding of the entire service that is being provided. Coupled with Service Asset and Configuration Management an understanding of the overall service is identified. This includes not just dependency/relationship data but also operating parameters, monitoring for known errors, and so on. Service level management (SLM) can provide input on negotiated service level objectives and so on. These processes are all interdependent and need to work together and share information.

IT has used monitoring tools for decades now to gain insight on how systems are operating. Usually tools would be purchased and then aspects of systems monitored based on what the tool could do and what the people implementing the tool knew about the system. As time went on, the tools evolved to trend data over time, generate alerts and alarms and send them via pages and emails and even trigger applications to execute predefined tasks. However, the processes that could leverage the tools didn’t keep pace.

A good deal of knowledge has built up over how to monitor certain systems (and now end-to-end services), but consistent manner to collect and apply knowledge in a relative short amount of time with high degree of success is lacking. This is a repeated theme we see in IT: technology-led approaches that deliver inconsistent results. Instead, what is needed is a process-led approach that not only delivers consistent results but can be evolved as well.

The Event Management process is a formal process that begins during Service Design and extends through Service Transition into Service Operation. It is tasked with the formal definition of events, including their identification criteria and the approved responses. It has a defined process owner and manager the same as other processes.

Finding the Needles

To level set, an event is a change in state. It could relate to hardware, software, people, facilities, environmentals, etc. For any data center, or IT organization overall, there is an unbelievably large number of events transpiring every second. Somewhere in that storm of events there are certain events that IT should know about. So, how do we find the proverbial needle in the haystack?

When we look at monitoring the IT landscape, what frequently happens is a new application is installed in a data center and operations then figures out how to monitor it. Even accepting some missteps and a sometimes steep learning curve, a complex system may not be monitored correctly for as long as a year. We need to shift the thinking to one of services and a service development lifecycle that takes all aspects of a service into account during development―including what events may happen and how to monitor for them.

With a properly designed and implemented Event Management process, the walls between development, test, and operations are broken down to allow for the understanding of the entire service that is being provided. Coupled with Service Asset and Configuration Management an understanding of the overall service is identified. This includes not just dependency/relationship data but also operating parameters, monitoring for known errors, and so on. Service level management (SLM) can provide input on negotiated service level objectives and so on. These processes are all interdependent and need to work together and share information.

The event documentation that is generated is just as vital as the development work relating to the monitoring and event tools. This documentation and the ability to review and discuss it leads to a deeper understanding of each service including causal relationships and efficient responses. This knowledge can be integrated with Knowledge Management, Incident Management, Problem Management, and other process areas to train employees, determine root cause, establish work-arounds, and ultimately help create better services through continuous process improvement.

Improving MTTR

Another benefit of effective Event Management to consider is improved availability as mean time to repair (MTTR) is reduced, often dramatically. This is because a large component of MTTR is simply detecting that an event has taken place. Then, when the event is detected, it must be diagnosed, repaired and the service recovered back into production. All these facets of an incident can be reduced through improved event automation and better training and preparedness of staff.

Another benefit is a reduction in unplanned work through improved effectiveness and efficiency of the Incident and Problem Management processes. The monitoring tools are now set up correctly and events can be identified and addressed rapidly (sometimes before users even notice). This reduces the firefighting where IT gets pulled off projects to establish why some IT service has failed. In other words, incidents can be addressed while still small and manageable versus ad hoc “all hands on deck” emergencies.

For groups that haven’t yet learned about Event Management, now is a good time to start. It offers very real benefits and quite often existing technology investments in monitoring can be leveraged. While an event correlation system is very beneficial, the process can still begin without it as the improved planning and communication about the overall services, how to monitor them, and how to respond can still yield very real benefits.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.