VMware Monitor
Problem Management - Problem logging
Regardless of the detection method, all the relevant details of the problem must be recorded so that a full historic record exists. This must be date and time stamped to allow suitable control and escalation.
A cross-reference must be made to the incident(s) which initiated the Problem Record – and all relevant details must be copied from the Incident Record(s) to the Problem Record. It is difficult to be exact, as cases may vary, but typically this will include details such as:
- User details
- Service details
- Equipment details
- Date/time initially logged
- Priority and categorization details
- Incident description
- Details of all diagnostic or attempted recovery actions taken.
Problem Categorization
Problems must be categorized in the same way as incidents (and it is advisable to use the same coding system) so that the true nature of the problem can be easily traced in the future and meaningful management information can be obtained.
Problem Prioritization
Problems must be prioritized in the same way and for the same reasons as incidents - but the frequency and impact of related incidents must also be taken into account. The coding system described earlier in Table 4.1 (which combines impact with urgency to give an overall priority level) can be used to prioritize problems in the same way that it might be used for incidents, though the definitions and guidance to support staff on what constitutes a problem, and the related service targets at each level, must obviously be devised separately. Problem prioritization should also take into account the severity of the problems. Severity in this context refers to how serious the problem is from an infrastructure perspective, for example:
- Can the system be recovered, or does it need to be replaced?
- How much will it cost?
- How many people, with what skills, will be needed to fix the problem?
- How long will it take to fix the problem?
- How extensive is the problem (e.g. how many CIs are affected)?
Other ITIL Processes
In order to have a good understanding of ITIL and the importance of configuration management, we first define what ITIL is: ITIL is literally a collection of documentation.
This documentation can help IT organizations implement the best practices. The documentation grows and grows as more successful techniques are documented and guidelines established for what can make others successful. The latest ITIL resources are published by the UK Office of Government Commerce (OGC).
Integrated service delivery refers to the need for Configuration Management, Change Management, Incident Management, Problem Management and Release Management processes that are linked together in a meaningful manner. For example, the process of releasing components to the live environment (the domain of Release Management) is also an issue for Configuration Management and Change Management whilst the Service Desk is primarily responsible for liaison between IT providers and the Users of services. This section highlights the links and the principal relationships between all the Service Management and other infrastructure management processes.
ITIL processes fall under Operational Layer or Tactical Layer, as follows:
| Operational Layer: | Configuration Management - Service Desk Management - Incident & Problem Management - Change Management - Release Management |
| Tactical Layer: | Service Level Management - Availability Management - Capacity Management - Continuity Management - Financial Management |