Runbook Lifecycle

A Runbook will typically follow one of the state transition journeys outlined below. This occurs regardless of whether a Runbook is within or outwith an Event. Therefore, when monitoring, reporting or executing events, the below holds true. However, as per the red wording below, any Runbook in an Event may have implications for other Runbooks or the overall Event itself.

Successfully Implemented Runbook

Successfully Implemented STP

The planned lifecycle for a successfully completed Runbook is shown above - these states are sequential and represent the ongoing data input and levels of assurance over a successful implementation execution:

  • Initial is the status when a Runbook has been created (including if a clone)
  • Construction signifies the Runbook schedule has been input
  • Review status occurs when a schedule has been added and all tasks approved
  • Scheduled signals the Runbook has been approved
  • Committed Runbook is when Commit has been clicked and the the scheduled STP is the plan of record and the basis for the expected execution of the STP
  • Active denotes the Runbook and tasks therein are ready for execution and individual activation. Real-time monitoring and schedule calculation is underway.  All pre-implementation tasks must have been completed as a pre-requisite to this state
  • Complete indicates the implementation phase has been successfully executed
  • Closed indicated that the post-implemetation has been completed subsequent to the Complete state being reached.

There are two other states (see following sections)

  • Suspended highlights the Runbook has been halted, and a decision to reactivate or abandon or back-out must follow
  • Abandoned, the Runbook was active and then abandoned (and therefore will not be progressed in its current format, although it can be cloned and form the basis of another, similar Runbook). Note: a Runbook doesn't need to have been suspended before it's abandoned).

Note:  when suspending or abandoning a Runbook that resides in an Event, the entire Event may require to be similarly actioned. Each Runbook may require to be individually suspended or abandoned, or alternatively some may be a mixture of those and / or completed. This would be decided via the Event command-and-control.

Successfully Backed Out Runbook

Successfully Backed Out STP

The lifecycle of a Backout Runbook adheres to the successful implementation lifecycle until Backout is invoked. The additional Backout lifecycle states are

  • Backing Out shows backout phase and tasks active and the backout is underway with real-time monitoring of backout underway
  • Backed Out highlights the completion of the backout implementation phase, i.e. the backout is complete
  • Backout Closed is when all backout post-implementation tasks have been completed. NB  If an STP has no post-implementation phase then an STP will transition from Backed Out directly to Backout Closed.

Abandoned Runbook

Abandoned STP

There may be reasons to abandon a Runbook without completing or backing out.  This option is available to Implementation Manager Users and is achieved via the Abandon button on the Maintain STP screen (114).

Suspended Runbook

Suspended STP

An active or backing out Runbook may be suspended by an Implementation Manager.  As part of suspension, the Implementation Manager must enter an <Estimated Resolution Time>. This ensures the real-time ICEFLO forecasting engine can recalculate projected start and end times and update the RAG status if required. This in turn highlights any remedial or other alternative action required to avoid an unplanned or unapproved outage.

Dormancy

STPs are given a Dormancy Threshold. On reaching this threshold they become Dormant. The Dormancy Threshold can be found on the Edit Runbook Details screen which is located in the Runbook Maintenance panel of the Maintain Runbook screen. The threshold is given by the system on the creation and reinstation of Runbooks.

The predetermined threshold by default is 3 days from the Service Impact time of an unlinked Runbook. Runbooks that are linked will only become Dormant when all of the Runbooks meet the dormancy criteria.

 

  • Initial Runbooks will become dormant after 7 days unless it has been given a schedule.
  • Construction - Runbooks in the state of construction will become Dormant 3 days from the Service Impact Time
  • Review - Runbooks in the state of Review will become Dormant 3 days from the Service Impact Time
  • Approved - Runbooks in the state of Approved will become Dormant 3 days from the Service Impact Time
  • Scheduled - Runbooks in the state of Scheduled will become Dormant 3 days from the Service Impact Time
  • Committed - Runbooks in the state of Committed will become Dormant 3 days from the Service Impact Time
  • Active - Runbooks in the sate of Active will become Dormant 3 days from the Service Impact Time
  • Comeplete - Runbooks in the state of complete will become Dormant 3 days from the Service Impact Time
  • Closed - Runbooks in a state of closed will never become Dormant.
  • Initial  Runbooks will become dormant after 7 days unless it has been given a schedule.
  • Construction - Runbooks in the state of construction will become Dormant 3 days from the Service Impact Time
  • Review - Runbooks in the state of Review will become Dormant 3 days from the Service Impact Time
  • Approved - Runbooks in the state of Approved will become Dormant 3 days from the Service Impact Time
  • Scheduled - Runbooks in the state of Scheduled will become Dormant 3 days from the Service Impact Time
  • Committed - Runbooks in the state of Committed will become Dormant 3 days from the Service Impact Time
  • Active - Runbooks in the sate of Active will become Dormant 3 days from the Service Impact Time
  • Backing Out - Runbooks in the state of Backing Out will become Dormant 3 days from the Service Impact Time
  • Backed Out - Runbooks in the state of Backed Out will become Dormant 3 days from the Service Impact Time
  • Backout Closed - Runbooks in the state of Backout Closed will never become Dormant

Runbooks in a state of Closed, Backout Closed and Abandoned will never become Dormant

Events

If a Runbook is part of an Event, whereby the timecalcs are 'managed' then the Runbook will automatically become Dormant once the Event is Closed. To Resume a Runbook which belongs to a Closed Event the Event must be re-opened.

Resume a Runbook

Runbooks can be Resumed by an Implementation Manager. Please note that if a Runbook has external dependencies, these Runbooks will also be Resumed.