SS - читать онлайн бесплатно полную версию книги . Страница 52
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 alerts
External source
Compile data from external sources, such as Service desk tickets, suppliers or systems (e.g. ERP, CRM)
Manual generation
Manually create or alter an event
Polling
Monitoring systems actively interrogate functional elements
Synthetic transactions
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 Managementfunction 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. Faultmanagement systems 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 services. This model is built on dependencies rather than topology – causality rather than correlation. Infrastructure events are then tied to corresponding business processes. The component-to-system-to-process linkage – also known as the Service Model – allows us to clearly identify the businessimpact 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 Services. 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.
8.2 Service interfaces
8.2.1 Characteristics of good service interfaces
The design of service interfaces is critical to service management. Highly usable service interfaces are necessary for service orientation. The principles of agency, specialization, coordination, encapsulation and loose coupling are possible because of effective interfaces between service assets and customer assets. Service interfaces are typically present at the point of utilization or service access points (Figure 8.4).
Figure 8.4 The critical role of service interfaces
Service access points are associated with one or more channels of service. User interfaces include those provided for the customer’s employees and other agents, as well as process-to-process interfaces. The Service interfaces should meet the basic requirements of warranty:
They should be easily located or ubiquitous enough, or simply embedded in the immediate environment or business context, as in the case of interfaces to software applications.
They should be available in forms or media that allow choice and flexibility for users. For example, there should be choice between staffed locations and automated self-service options, and choice between a browser and a mobile phone as access points.
They should be available with enough capacity to avoid queuing or backlog when supporting concurrent use by many users. The presence of other users should not be noticeable (non-rival use).
They should accommodate users with varying levels of skills, competencies, backgrounds and disabilities.