CMDB - Availability Management

Last modified on 2023/03/28 16:31


Availability management enables the IT Department to check if the agreements signed with users in terms of availability and service are being fulfilled for each configuration item (CI) over a given period (e.g. week or month).

  • Availability objectives are expressed in the availability percentage for a period of service hours, by calculating the difference between:
    • Availability defined in the SLA availability target which takes the normal service hours of the CI into account.
    • Unavailability of the CI, determined by the occurrence of unavailability periods during service hours.
  • Agreements are considered fulfilled for the CI when the availability difference is positive for the analyzed period.
    • The greater the difference, the longer the service availability or the shorter its recovery time after a disruption.

You can use different Mean Time indicators (MT...) to measure service reliability. These Business Intelligence tools enable the IT Department to adopt the required strategies to correct issues and improve the service provided to users.

example  Schedule database maintenance operations to run on weekends, plan to purchase another Oracle server if the current server is often unavailable


The Oracle Server CI is associated with an SLA availability target of 95%.

  • Availability calculated for one month = 97%  ==> Difference as regards the IT Department's availability target of 95% is 2%. This shows that users were able to enjoy the service fully and that the agreement was fulfilled.
  • Availability calculated for one month = 91%  ==> Difference = -4%, showing that users were unable to enjoy the service level they expected during the analyzed period.

Best Practice

  • You should always run availability calculations for a given period. For a given CI, the difference may vary for two periods because unavailability periods may differ for a given SLA availability target.

Menu access

Extended CMDB > Availability

Description of Mean Time indicators

          MTTX schema.png

MTBF - Mean Time Between Failures: Average time between successive disruptions

  • This corresponds to the average time between the start of a service and the start of its disruption, e.g. start of downtime, excluding scheduled or deliberate downtime.
  • MTBF (hours) = (Number of hours in the period – Number of unavailability hours) / Number of disruptions

MTRS - Mean Time to Restore Service: Average time for restoring a service

  • This corresponds to average unavailability time from the start of service disruption to its full recovery.
  • MTRS (hours) = Number of unavailability hours / Number of disruptions

MTBSI - Mean Time Between Service Incidents: Average time between two service disruptions

  • This corresponds to the average time between the start of each service failure. 
  • MTBSI (hours) = MTBF + MTRS

MTTR - Mean Time To Repair: Average time for repairing the service

  • This corresponds to the average time of an incident associated with unavailability.
  • This does not include the time required for restoring the service.
  • MTTR (hours) = Number of hours in the incident / Number of disruptions

Calculation rules

  • Mean Time indicators are calculated in hours. There are no negative values.
  • If there is no unavailability or if unavailability only occurs after service hours, then a dash delete is displayed.
  • Unavailability ratios are not used when calculating Mean Time indicators.
  • In the event of overlapping, unavailability periods are not aggregated.

    example   For example, a CI is unavailable from 8 am to 10 am and from 9 am to 11 am.

    • There are two separate unavailability periods.
    • The overlapping period is not taken into account, so total unavailability time is three hours instead of four.
  • If the end date of the period is in the future, the Total period parameter will run up to the end of this period and not up to the current date.

    example   Current date = July 7 ==>  The end date of the Next Month period = March 31 instead of July 7 (current date)

  • If there is no end date for the incident or unavailability period, then it is considered to be equal to the end of the specified period and not the current date.
Powered by XWiki © EasyVista 2024