Phased rollout This documentation supports the 21.05 version of BMC Helix ITSM: Service Desk. To view an earlier version, select the version from the Product version menu.

Resolving a problem investigation by using a change request rollback


This user scenario describes how to resolve a problem investigation by rolling back a change request. Incident Management, Problem Management, and BMC Helix ITSM: Change Management must be installed to follow this user scenario.

Scenario

Bob Baxter, the problem coordinator at the Calbro Service Desk, performs an incident request review by searching incident requests registered against the payroll service. He reviews the history of the associated CIs and recognizes a trend in problems that are related to common changes to a specific CI. He creates a change request to roll back changes that affect that CI. A request for change (RFC) is submitted to Mary Mann, the change manager in Front Office Support, for approval.

Ian Plyment, the specialist, approves and successfully implements the change. The change manager creates a broadcast to alert users. Future incidents are successfully averted.

Workflow

The following table describes the typical steps involved in this user scenario: 

Role

Actions

Explanation

Problem coordinator

The problem coordinator performs an incident request review. From the Incident console, the problem coordinator creates a custom search with the following characteristics:

  • Service = Payroll
  • Impact => 2-Significant/Large OR 1-Extensive/Widespread
  • Last Resolved Date >=02/19/2020

For the purpose of this example, assume today's date is 06/19/2020. Therefore, the Last Resolved Date is four months ago.

The problem coordinator looks for incident request records that have not yet been linked to a problem investigation.

Bob Baxter, the problem coordinator, performs an incident request review by searching incident requests registered against the payroll service, for which he is the problem coordinator.

Problem coordinator

  1. The problem coordinator opens an incident request that is related to the payroll service and creates a problem investigation.
  2. The incident record's details are copied from the incident request record to the Problem form, and a relationship is created between the problem investigation record and the incident request records.
  3. The problem coordinator completes the Problem form.

Bob spots a trend. Numerous incidents have been reported against the payroll server CI, which is critical to making that service available. He also discovers that the server recently was the subject of a change.

Bob reviews the change related to the server and determines that the recent change to the CI was the root cause of those incident requests.

Bob creates a problem investigation record directly from one of the incident request records, which transfers all relevant information from the incident request and automatically establishes the relationship between the incident request and the problem investigation.

Problem coordinator

  1. The problem coordinator creates relationships between the problem investigation and all of the related incident requests.
  2. The problem coordinator creates a relationship between the problem investigation and the original change request that is responsible for triggering the incident requests.

Bob then relates the other incident requests, the original change request, and the CI to the problem investigation.

Problem coordinator

The problem coordinator creates a known error:

  1. The problem coordinator sets the Status field to Completed and the Status Reason field to Known Error.
    This opens the Known Error form and creates a relationship between the known error and the problem investigation.
  2. The problem coordinator completes information on the form. The problem coordinator enters his name as the assigned problem coordinator. The problem coordinator enters the change coordinator's name as the known error assignee, and sets the status to Assigned.

Bob determines that the best way to prevent similar incident requests from recurring is to roll back the original change. To request the rollback, Bob creates a known error from the problem investigation. He assigns the known error to Mary Mann, the change coordinator.

Change coordinator

  1. The change coordinator opens the known error record and creates a change request.
    This opens the Change Request form and creates a relationship between the known error and the change request. It also copies information from the known error record to the change request record.
  2. The change coordinator completes the required information and saves the change request.
  3. The change coordinator moves the change request through the lifecycle until it is approved and the dates are set.
  4. To alert users about the rollback, the change coordinator creates a broadcast.

Mary receives the known error and reviews it. She agrees that the rollback is required and creates a change request from the known error.

Mary moves the record through the change request lifecycle.

As part of the change request, the change coordinator creates a broadcast alerting users to the incorrect original change and the symptoms in the defective CI. The broadcast mentions the new change and the time when the CI will be unavailable (while the change is being executed). The broadcast also explains that the change was necessary to avoid further incoming related incidents.

Change coordinator

  1. The change coordinator assigns the change request to a specialist.
  2. The change coordinator adds a task to the change request.
  3. The change coordinator relates the CIs to the change request.
  4. The change coordinator moves the change request to the Implement stage.

On the change request record, Mary creates a task to roll back the CI and assigns the change request to Ian Plyment, the specialist who will perform the work. Mary also relates the CI to the change request.

Specialist

The specialist closes the tasks after performing them:

  1. From the Change Management Support console, the specialist searches for assigned tasks.
  2. After performing the task, the specialist records information about performing the task and changes the status to Closed.

Ian rolls back the change to the CI. When he finishes the last task, the system notifies Mary that the tasks are closed.

Change coordinator

The change coordinator completes the change request:

  1. The change coordinator moves the change request to the Closed stage.
  2. The change coordinator enters the performance rating and the actual dates of the change.

Mary completes the change request record and removes the broadcast because it is no longer relevant.

Problem coordinator

The problem coordinator closes the problem investigation and known error:

  1. The problem coordinator confirms that the rollback has solved the problem with the payroll server.
  2. The problem coordinator opens the problem investigation record and checks that the details are all correct, and then sets the status to Closed.
  3. The problem coordinator opens the known error and sets the status to closed. The problem coordinator records a summary of how the known error was resolved.

Bob is notified that the rollback was completed. Bob verifies that the rollback fixed the problem, and then changes the status of the problem investigation and known error to closed.

Result

As a result of the incident review and root cause analysis, the cause of incidents is determined to be the changes on the payroll server. The changes on this server are rolled back and users are alerted through a broadcast that the payroll server will be undergoing a scheduled maintenance. 

Benefit

By performing this rollback, Bob makes sure that similar incidents do not occur in the future.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*