Reporting and action

Monitoring in Test Environments

As with any IT Infrastructure, a Test Environment will need to define how it will use monitoring and control. These controls are more fully discussed in the Service Transition publication.

• Monitoring the Test Environment itself: A Test Environment consists of infrastructure, application s and processes that have to be managed and controlled just as any other environment. It is tempting to think that the Test Environment does not need rigorous monitoring and control because it is not a live environment. However, this argument is not valid. If a Test Environment is not properly monitored and controlled, there is a danger of running the tests on equipment that deviates from the standard s defined in Service Design.
• Monitoring items being tested: The results of testing have to be accurately tracked and checked. Also it is important that any monitoring tools that have been built into new or changed services have to be tested as well.

‘A report alone creates awareness; a report with an action plan achieves results.’

Reporting and dys function

Practical experience has shown that there is more reporting in dysfunctional organizations than in effective organizations. This is because reports are not being used to initiate pre-defined action plan s, but rather:

• to shift the blame for an incident
• to try to find out who is responsible for making a decision
• as input to creating action plans for future occurrences.

In dysfunctional organizations a lot of reports are produced which no one has the time to look at or query.

Monitoring without control is irrelevant and ineffective. Monitoring should always be aimed at ensuring that service and operational objective s are being met. This means that unless there is a clear purpose for monitoring a system or service, it should not be monitored.

This also means that when monitoring is defined, so too should any required actions. For example, being able to detect that a major application has failed is not sufficient. The relevant Application Management team should also have defined the exact steps that it will take when the application fails.

In addition, it should also be recognized that action may need to be taken by different people, for example a single event (such as an application failure) may trigger action by the Application Management team (to restore service), the users (to initiate manual processing) and management (to determine how this event can be prevented in future).

The implications of this principle are outlined in more detail in relation to Event Management (see section 4.1).

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