1. Service Design – Figure 4.15 Expended Incident Lifecycle

2. Optimum

3. Service Design – Figure 4.15 Expended Incident Lifecycle An aim of Availability Management is to ensure the duration and impact from incidents impacting IT services are minimized, to enable business operations to resume as quickly as is possible. The analysis of the 'expanded incident lifecycle' lifecycle' enables the total IT service downtime for any given incident to be broken down and mapped against the major stages through which all incidents progress (the lifecycle). Availability Management should work closely with Incident Management and Problem Management in the analysis of all incidents causing unavailability unavailability.

4. Service Design – Figure 4.15 Expended Incident Lifecycle Service Available Service Available Service Available Service Available

5. Service Design – Figure 4.15 Expended Incident Lifecycle Service Available Service Available Service Available Service Available

6. Service Design – Figure 4.15 Expended Incident Lifecycle Service Available Service Available Service Available Service Available Time to Restore MTRS – Mean Time to Restore – the average time to restore service measured from the start of the incident until the service is verified as in the same operational state as before the incident.

7. Service Design – Figure 4.15 Expended Incident Lifecycle Service Available Service Available Service Available Service Available MTBSI MTBSI – Mean Time Between Service Incidents – the average time between service incidents. Time Between Incident Time Between Incident

8. Service Design – Figure 4.15 Expended Incident Lifecycle Service Available Service Available Service Available Service Available MTBF MTBF – Mean Time Between Failures – the average time between the restoration of a service and a subsequent failure. Time Between Failure Time Between Failure

9. Service Design – Figure 4.15 Expended Incident Lifecycle

10. Incident Start Service Restored Detect Detection Detection - the time at which the IT service provider organization is made aware of an incident.

11. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Start Service Restored Detect Diagnose Diagnosis Diagnosis - the time at which diagnosis to determine the underlying cause has been completed.

12. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Start Service Restored Detect Diagnose Repair Repair Repair - the time at which the failure has been repaired/fixed.

13. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Start Service Restored Detect Diagnose Repair Repair - the time at which the failure has been repaired/fixed.

14. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Start Service Restored Detect Diagnose Repair Recover Recover Recover - the time at which component recovery has been completed.

15. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Start Service Restored Detect Diagnose Repair Recover Restore Restore Restore - the time at which normal business service is resumed.

16. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Start Service Restored Detect Diagnose Repair Recover Restore Restore - the time at which normal business service is resumed.

17. Service Design – Figure 4.15 Expended Incident Lifecycle IncidentIncident Time Between Incidents

18. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Incident Time to Repair (Downtime) Restoration Uptime

19. Service Design – Figure 4.15 Expended Incident Lifecycle Incident Incident Restoration Time to Repair (Downtime) Dectection Diagnosis Repair Dectection Elapsed Time Response Time Restortion Time Recovery Time Uptime

20. Service Design – Figure 4.15 Expended Incident Lifecycle