Availability: in itself quite simple and yet surprisingly complex

Data sources and results

Final results or detailed data

Data and measured values for calculating the availability of an IT system or service usually come from two sources. Either “final” values in percentages are supplied or raw data is available for calculation. Ready-made results can be collected manually or automatically using a monitoring system. The manual method is useful for isolated systems. Monitoring tools are usually used. However, not all of these tools have data interfaces for automatic integration of relevant data. In that case, manual effort is also required to supplement the measured values collected from different systems for a plausible final result.

A special case is when an IT service provider not only provides its own services, but also acts as an intermediary for third-party services. If it has agreed service level agreements (SLAs) as a general contractor, it is responsible for ensuring that its subcontractors deliver the performance data so that it, as the contractual partner, can prove the availability of the system. The method of determination is also specified in the contract. This can lead to complexities, because the methods of the “intermediary” and those of its suppliers must be specified. Furthermore, all data should come in on time so that reports are ready at the agreed time.

Components, services, tickets – sources for detailed data

If an availability report is based on a company’s own calculations, then the question arises on which basis the data is collected. The status or failure data for IT components often comes from a wide variety of infrastructure management systems, and in rare cases it is also collected manually. The methods of collection and the formats in which data is prepared are as varied as the monitoring systems. Common methods are the regular recording of status values, such as checking availability every minute, or the evaluation of downtime lists (event logs). Availability per measurement interval can also be used as an evaluation criterion. This shows whether a system or component was available continuously or only intermittently (as a percentage) during a specific period.

Due to the numerous different systems, methods and formats that are generally used for monitoring and recording availability data, the results must be converted into a defined standard format. This is the only way to produce a valid and comprehensible statement on overall availability.

Detailed data for IT services

The situation is different when it comes to collecting detailed data for IT services such as e-mail, CRM or SAP. For such complex services, the data of individual sub-services is often correlated to produce an overall result. There are various methods for doing this. One option is single point of failure, when the failure of one component threatens the entire service. Systems in which essential components are available several times over, the redundancy method is the best option. Availability is assumed when at least one of the components is available. A further method for correlating the component detail data is the Quorum. It is used for example with terminal server farms. Here an availability can exist by definition already, even if half of the servers are available.

Correlation structures are also important when calculating the overall result. These can be simple, fixed structures, such as system – cluster – server – process, which represent the overall service.

In the case of more complex services such as SAP, there are often multiple service trees containing sub-services, which in turn provide correlated results from external data sources.

Availability data is also collected from a user perspective. Measured values from end-user experience management or application performance management systems are used for this purpose. These perform synthetic measurements via monitoring agents for the permanent recording of comparable values. The calculations are made by aggregating parallel measurements on several clients to produce an overall result. Here, too, the correlation methods described are used to evaluate availability.

Real User Monitoring (RUM) records the behavior of active users. Gaps occur, for example, when no one is currently working with the system. In addition, the measured values depend on individual user behavior. Compared to synthetic measurement, RUM is therefore very well suited for other measurements such as abort rates or the proportion of successful transactions.

The user has the floor: detailed data from support tickets

Another option for calculating availability is to evaluate automatically or manually generated incident tickets from the IT support or user help desk. In manual processing, individual tickets must be assigned to respective components or services. This is not easy, because the user only reports the incident; the service employee has to find the affected components and services. Another challenge is assigning tickets to reporting periods, because the lifecycle of a ticket can span a period of several weeks or months. It must be clear whether and how open tickets are included in the availability calculation. In addition, it should be defined whether changes to active tickets have a retroactive effect on the results of a reporting period that has already been completed.

Failure of measuring devices: Courage to fill the gap?

It must be clear how data gaps are to be handled. After all, measuring devices may fail at any time or results may not be available for other technical reasons. It must be decided whether such gaps are assessed as “available”, “not available” or “not measured” in terms of performance and whether they lead to a reduction in service time, which in turn affects the calculation of availability. It should also be clear whether a minimum length of individual outages plays a role in the calculation. For example, outages below a certain length might not be considered.

There are a variety of data sources as well as methods and formats that can be selected for availability calculation. However, in order to make a valid statement about the availability of the IT system or IT service, this data must be correlated by mutual agreement and converted into a standard format