Errors detected in the development environment

Major Problem Review

Problem Closure

When any change has been completed (and successfully review ed), and the resolution has been applied, the Problem Record should be formally closed – as should any related Incident Record s that are still open. A check should be performed at this time to ensure that the record contains a full historical description of all event s – and if not, the record should be updated.

The status of any related Known Error Record should be updated to shown that the resolution has been applied.

After every major problem (as determined by the organization ’s priority system), while memories are still fresh a review should be conducted to learn any lessons for the future. Specifically, the review should examine:

• Those things that were done correctly
• Those things that were done wrong
• What could be done better in the future
• How to prevent recurrence
• Whether there has been any third-party responsibility and whether follow-up actions are needed.

Such reviews can be used as part of training and awareness activities for support staff – and any lessons learned should be documented in appropriate procedure s, work instruction s, diagnostic script s or Known Error Records. The Problem Manager facilitates the session and document s any agreed actions.

The knowledge learned from the review should be incorporated into a service review meeting with the business customer to ensure the customer is aware of the actions taken and the plan s to prevent future major incident s from occurring. This helps to improve customer satisfaction and assure the business that Service Operation s is handling major incidents responsibly and actively working to prevent their future recurrence.

It is rare for any new application s, systems or software release s to be completely error -free. It is more likely that during testing of such new applications, systems or releases a prioritization system will be used to eradicate the more serious fault s, but it is possible that minor faults are not rectified – often because of the balance that has to be made between delivering new functionality to the business as quickly as possible and ensuring totally fault-free code or component s.

Where a decision is made to release something into the production environment that includes known deficiencies, these should be logged as Known Errors in the KEDB, together with details of workaround s or resolution activities. There should be a formal step in the testing sign-off that ensures that this handover always takes place (see Service Transition publication).

Experience has shown if this does not happen, it will lead to far higher support cost s when the user s start to experience the faults and raise incidents that have to be re-diagnosed and resolved all over again!

4.4.6 Triggers, input and output/inter-process interfaces

The vast majority of Problem Record s will be triggered in reaction to one or more incidents, and many will be raised or initiated via Service Desk staff. Other Problem Records, and corresponding Known Error Records, may be triggered in testing, particularly the latter stages of testing such as User Acceptance Testing/Trials (UAT), if a decision is made to go ahead with a release even though some fault s are known. Suppliers may trigger the need for some Problem Record s through the notification of potential faults or known deficiencies in their products or services (e.g. a warning may be given regarding the use of a particular CI and a Problem Record may be raised to facilitate the investigation by technical staff of the condition of such CIs within the organization ’s IT Infrastructure).

The primary relationship between Incident and Problem Management has been discussed in detail in paragraphs 4.2.6 and 4.4.5.1. Other key interfaces include the following:

• Service Transition
• Change Management: Problem Management ensures that all resolution s or workaround s that require a change to a CI are submitted through Change Management through an RFC. Change Management will monitor the progress of these changes and keep Problem Management advised. Problem Management is also involved in rectifying the situation caused by failed changes.
• Configuration Management: Problem Management uses the CMS to identify faulty CIs and also to determine the impact of problem s and resolution s. The CMS can also be used to form the basis for the KEDB and hold or integrate with the Problem Records.
• Release and Deployment Management: Is responsible for rolling problem fixes out into the live environment. It also assists in ensuring that the associated known error s are transferred from the development Known Error Database into the live Known Error Database. Problem Management will assist in resolving problems caused by faults during the release process.
• Service Design
• Availability Management: Is involved with determining how to reduce downtime and increase uptime. As such, it has a close relationship with Problem Management, especially the proactive areas. Much of the management information available in Problem Management will be communicated to Availability Management.
• Capacity Management: Some problems will require investigation by Capacity Management teams and techniques, e.g. performance issues. Capacity Management will also assist in assessing proactive measures. Problem Management provides management information relative to the quality of decisions made during the Capacity Planning process.
• IT service Continuity: Problem Management acts as an entry point into IT Service Continuity Management where a significant problem is not resolved before it starts to have a major impact on the business.
• Continual Service Improvement
• Service Level Management: The occurrence of incidents and problems affects the level of service delivery measured by SLM. Problem Management contributes to improvements in service level s, and its management information is used as the basis of some of the SLA review component s. SLM also provides parameters within which Problem Management works, such as impact information and the effect on services of proposed resolutions and proactive measures.
• Service Strategy
• Financial Management: Assists in assessing the impact of proposed resolution s or workaround s, as well as Pain Value Analysis. Problem Management provides management information about the cost of resolving and preventing problem s, which is used as input into the budgeting and accounting system s and Total Cost of Ownership calculations.

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