Service analytics and instrumentation

Information is necessary but not sufficient for answering questions such as why certain data is the way it is and how it is likely to change in the future. Information is static. It only becomes knowledge when placed in the context of patterns and their implications. Those patterns give a high level of predictability and reliability about how the data will change over time. By understanding patterns of information we can answer ‘How?’ questions such as:

• How does this incident affect the service?
• How is the business impacted?
• How do we respond?

This is Service Analytics.

To understand things literally means to put them into a context. Service Analytics involves both analysis, to produce knowledge, and synthesis, to provide understanding. This is called the DIKW hierarchy (Figure 8.3).

Figure 8.3 The flow from data to wisdom

While data does not answer any questions, it is a vital resource. Most organizations consider this capability in the form of instrumentation. The term instrumentation describes the technologies and techniques for measuring the behaviours of infrastructure elements. Instrumentation reports actual or potential problems and provides feedback after adjustments. Most organizations already have an installed base of instrumentation monitoring infrastructure elements similar to those in Table 8.1.

Technique	Action
Asynchronous capture	Passive listeners scan for alert s
External source	Compile data from external sources, such as Service desk tickets, supplier s or systems (e.g. ERP, CRM)
Manual generation	Manually create or alter an event
Polling	Monitoring systems actively interrogate functional elements
Synthetic transaction s	Simulate the end- user experience through known transactions

Table 8.1 Instrumentation techniques

While data from element instrumentation is absolutely vital, it is insufficient for monitoring services. A service’s behaviour derives from the aggregate behaviour of its supporting elements. While instrumentation can collect large amounts of raw data, greater context is needed to determine the actual relevance of any data. Information is the understanding of the relationships between pieces of data. Information answers four questions: Who, What, When and Where? This can be thought of as Event, Fault and Performance Management. The Event Management function refines instrumentation data into those that require further attention. While the line between instrumentation and Event Management can vary, the goal remains the same: create usable and actionable information. Table 8.2 describes common Event Management techniques.

Technique	Action
Compression	Consolidate multiple identical alarms into a single alarm
Correlation	See if multiple alert sources occurring during a short period of time have any relationship
Filtering	Apply rules to a single alert source over some period of time
Intelligent monitoring	Apply adaptive instrumentation
Roll-up	Compress alerts through the use of hierarchical collection structures
Verification	Actively confirm an actual incident

Table 8.2 Event Management techniques

A fault is an abnormal condition that requires action to repair, while an error is a single event. A fault is usually indicated by excessive errors. A fault can result from a threshold violation or a state change. Performance, on the other hand, is a measure of how well something is working. The function of the operations group begins with fault management. But as this function matures from reactive to proactive, the challenge becomes performance management. Fault management system s usually display topology maps with coloured indicators. Typically they have difficulties in dealing with complex objects that span multiple object types and geographies. Further context is needed to make this information useful for services. Begin by transitioning from information to knowledge.

Service Analytics is useful to model existing infrastructure components and support services to the higher-level business service s. This model is built on dependencies rather than topology – causality rather than correlation. Infrastructure events are then tied to corresponding business process es. The component -to-system-to-process linkage – also known as the Service Model – allows us to clearly identify the business impact of an event. Instead of responding to discrete events, managers can characterize the behaviour of a service. This behaviour is then compared to a baseline of the normal behaviour for that time of day or business cycle.

With Service Analytics, not only can an operations group do a better job of identifying and correcting problems from the user ’s standpoint, it can also predict the impact of changes to the environment. This same model can be turned around to show business demand for IT Service s. This is a high leverage point when building a dynamic provisioning or on-demand environment.

This is as far along the DIKW hierarchy as modern technologies allow. It is well understood that no computer-based technology can provide wisdom. It requires people to provide evaluated understanding, to answer and appreciate the ‘Why?’ questions. Moreover, the application of intelligence and experience is more likely to be found in the organizational processes that define and deliver service management than in applied technologies. Section 9.4 outlines some of the challenges in measurement that can be addressed by Service Analytics.

Дата добавления: 2015-11-14