Availability of IT services really matters. When services that a customer expects to be able to access aren’t available, that customer is going to be unhappy. After all, why should the customer pay for a service that isn’t there when they need it? This, of course, is why an agreed measure of service availability is so often a key performance indicator (KPI).
IT staff often work very hard to see that the agreed target is met, and provide figures proving it has been met when reporting to customers. Typically, IT organizations use a percentage, such as 99.999% availability, to do this. Unfortunately, this sometimes means that IT service organizations focus on the percentage measure and lose sight of their true goal – providing value for customers.
The trouble with percentage availability
One of the simplest ways to calculate availability is based on two numbers. You agree the amount of time that the service should be available over the reporting period. This is the agreed service time (AST). You measure any downtime (DT) during that period. You take the downtime away from the agreed service time, and turn this into a percentage.
If AST is 100 hours and downtime is 2 hours then the availability would be:
The trouble with this is that, while this calculation is easy enough to perform, and collecting the data to do it seems straightforward, it’s really not at all clear what the number you end up with is actually telling you. I’ll go into a bit more detail about this later in the blog.
Worse still, from the customer’s point of view, you may be reporting that you have met agreed goals, while leaving the customer totally unsatisfied.
Customers are only interested in percentage availability insofar as it correctly identifies their ability to use IT services to support business processes – and a blanket percentage figure is probably not going to do that. A meaningful availability report needs to be based on measurements that describe things the customer cares about, for example, the ability to send and receive emails, or to withdraw cash from ATMs.
Defining availability targets
If you want to measure, document, and report availability in ways that will be helpful to your organization and your customers you need to do two things. Firstly, you need to understand the context. To do this you’ll need to talk to your customers.
Secondly you need to think very carefully about a range of practical issues: what will you measure, how will you collect your data, and how will you document and report your findings.
Talking to customers
Before you do anything else, you need to work out what it is that your customers need availability for, and what impact the loss of availability has on them. This will allow you to agree realistic goals that consider technology, budgetary, and staffing constraints. In other words, you need to talk to your customers to ensure you understand what they need and, if necessary, to help them understand that “I want it to be available all the time” is probably going to cost more than it’s ever going to be worth.
But what exactly should you be talking to your customers about? An excellent starting point is the impact of downtime. Here are five questions you should consider asking:
- Which of your business functions are so critical that protecting them from downtime is a priority?
- How does the length of any downtime affect your business?
- How does the frequency of downtime affect your business?
- What impact does downtime have on your organization’s productivity?
- What impact does downtime have on your organization’s customers?
Critical business functions
Most IT services support several business processes, some of these are critical and others are less important. For example, an ATM may support cash dispensing and statement printing. The ability to dispense cash is critical, but if the ATM can’t print statements this has a much lower impact.
You need to talk to your customers and reach agreement about the importance of the various functions to their business. You may find it helpful to draw up a table that indicates the business impact that follows losing each of these functions relative to one another. Table 1 is an example:
Table 1 – Percentage degradation of service
|IT function that is not available||% degradation of service|
|Reading public folders||50%|
|Updating public folders||10%|
|Accessing shared calendars||30%|
|Updating shared calendars||10%|
NB: Figures are not intended to add up to 100%
It’s clear from this table that the service has no value at all if it cannot send and receive emails, and that the value of the service is reduced to half its normal level if public folders cannot be read. This tells the IT organization where to focus their efforts when designing and managing the email service.
Duration and frequency of downtime
You need to find out how the customer’s business is affected by both the frequency and the duration of downtime.
I’ve already mentioned that percentage availability may not tell you enough to be of value. When a service that should be available for 100 hours has 98% availability that means there were two hours downtime. But this could mean a single two-hour incident, or many shorter incidents. The relative impact of a single long incident or many shorter incidents will be different, depending on the nature of the business and the business processes involved.
For example, a billing run that takes two days to complete and must be restarted after any outage will be seriously impacted by every short outage, but one outage that lasts a long time may be less significant. On the other hand, a web-based shopping site may not be impacted by a one-minute outage, but after two hours the loss of customers could be significant. Once you know the likely impact, you’re in a much better position to put in place infrastructure, applications, and processes that will really support the customer, to devise meaningful targets, and to find ways of documenting and reporting them appropriately.
Here’s an example of how you could measure and document availability to reflect the fact that the impact of downtime varies:
Table 2 – Outage duration and maximum frequency
|Outage duration||Maximum frequency|
|Up to 2 minutes||2 events per hour|
5 events per day
10 events per week
|2 minutes to 30 minutes||2 events per week|
6 events per quarter
|30 minutes to 4 hours||4 events per year|
|4 hours to 8 hours||1 event per year|
If you use a table like this when you’re discussing the frequency and duration of downtime with your customers, the numbers are likely to be much more useful than percentage availability, and they’ll certainly be more meaningful to your customers.
Downtime and productivity
I’ve said that percentage availability is not very useful for talking to customers about the frequency and duration of downtime. In contrast, when you discuss the impact of downtime on productivity, percentage impact can be a very useful measure indeed.
Most incidents don’t cause complete loss of service for all users. Some users may be unaffected, while others have no service at all. At one extreme, there may be a single user with a faulty PC who cannot access any services. You might class this as 100% loss of service, but this would leave IT with a totally unrealistic goal, and would not be a fair measurement of availability.
At the opposite extreme, you might decide to say that a service is available so long as someone can still access it. However, you don’t need much imagination to understand how customers would feel if a service is being reported as available while many people just can’t access it.
One way you can quantify impact is to calculate the percentage of user minutes that were lost. To do this:
- Calculate the PotentialUserMinutes. This is the total number of users times the length of time that they work. For example, if you have 10 staff who work for 8 hours then the PotentialUserMinutes is 10 x 8 x 60 = 4800
- Calculate the UserOutageMinutes. This is the total number of users who were not able to work, multiplied by the time they were unable to work. For example, if an incident prevented 5 people from working for 10 minutes then the UserOutageMinutes is 50.
- Calculate the percentage availability using a very similar formula to the one we saw earlier
In this example, you would calculate the availability as:
You can use this same technique to calculate the impact of lost availability of IP telephony in a call center in terms of PotentialAgentPhoneMinutes and LostAgentPhoneMinutes; and for applications that deal with transactions or manufacturing you can use a similar approach to quantify the business impact of an incident. You compare the number of transactions that would have been expected without downtime to the number of actual transactions, or the amount of production that you would have predicted to the actual production.
Measuring and reporting availability
After you’ve agreed and documented your availability targets, you need to think about practical aspects of how you can measure and report availability. For example:
- What will you measure?
- How will you collect your data?
- How will you document and report your findings?
What to measure
It’s essential to measure and report availability in terms that can be compared to targets that have been agreed with customers and that are based on a shared understanding of what the customer’s availability needs actually are. The targets need to make sense to the customer, and to ensure that the IT organization’s efforts are focused on providing support for the customer’s business needs.
Usually, the targets will form part of a service level agreement (SLA) between the IT organization and the customer – but be careful that meeting numbers in an SLA does not become your goal. The numbers in the SLA are simply agreed ways of measuring, the real goal is to deliver services that meet your customers’ needs.
How to collect your data
There are many different ways that you could collect data about IT service availability. Some of these are simple, but not very accurate, others are more expensive. You may want to focus on just one approach, or you may need to combine some of these to generate your reports.
Collecting data at the service desk
One way to collect availability data is via the service desk. Service desk staff identify the business impact and duration of each incident as a routine part of managing incidents. You can use this data to identify the duration of incidents and the number of users impacted.
This approach is generally fairly inexpensive. However, it can lead to disputes about the accuracy of the availability data.
Measuring the availability of infrastructure and applications
This approach involves instrumenting all the components required to deliver the service and calculating service availability based on understanding how each component contributes to the end-to-end service.
This can be very effective, but may miss subtle failures, for example a minor database corruption could result in some users being unable to submit particular types of transaction. This method can also miss the impact of shared components, for example one of my customers had regular downtime for their email service due to unreliable DHCP servers in their HQ, but the IT organization did not register this as email downtime.
Using dummy clients
Some organizations use dummy clients to submit known transactions from particular points on the network to check whether the service is functioning.
This does actually measure end-to-end availability. Depending on the size and complexity of the network this can be quite expensive to implement, and it can only report the availability from the particular dummy clients. This means that subtle failures may be missed, for example if a change means that clients running a particular web browser no longer work correctly, but the dummy clients use a different browser.
Tools that support this data collection often report service performance, as well as availability, and this can be a useful addition.
Some organizations include code in their applications to report end-to-end availability. This can actually measure end-to-end service availability, provided that the requirement is included early in the application design. Typically, this will include code in the client application as well as on the servers.
When this is done well it can not only collect end-to-end availability data, but it can also identify exactly where a failure has occurred, helping to improve availability by reducing the time needed to resolve incidents.
How to document and report your findings
When you have collected availability data, you need to consider how this should be reported to customers.
Plan your downtime
One aspect of availability measurement and reporting that’s often overlooked is planned downtime. If you forget to factor in planned downtime when you’re working out how to report availability, you could end up reporting availability figures that don’t fairly reflect your service provision.
There are several ways to make sure that planned downtime doesn’t accidentally end up inflating the availability statistics. One is to have the planned downtime happen during a specific window that’s not included in availability calculations. Another is to schedule planned downtime. For example, some organizations may not count downtime that has been scheduled a month in advance.
Whatever you decide to do, it’s important that your SLA clearly defines how planned downtime will be reported.
Agree your reporting period
Earlier in this blog, I talked about the limitations of percentage availability as a useful measure. Nevertheless, it does have its uses and it continues to be widely used. So, it’s important to understand that you need to specify the time period over which calculation and reporting take place, as this can have a dramatic effect on the numbers that you’ll be reporting.
For example, let’s consider an IT organization that has agreed a 24×7 service and an availability of 99%. Suppose there’s an eight-hour outage:
- If we report availability every week then the AST (Agreed Service Time) is 24 x 7 hours = 168 hours
- Measured monthly the AST is (24 x 365) / 12 = 730 hours
- Measured quarterly the AST is (24 x 365) / 4 = 2190 hours
Putting these numbers into the availability equation gives:
- Weekly availability = 100% x (168 – 8) / 168 = 95.2%.
- Monthly availability = 100% x (730 – 8) / 730 = 98.9%
- Quarterly availability = 100% x (2190 – 8) / 2190 = 99.6%
Each of these is a valid figure for the availability of the service, but only one of them shows that the target was met.
Almost every IT organization that I’ve worked with measures and reports the availability of their services. The really great IT departments work with their customers to optimize their investment and deliver levels of availability that delight. Sadly, many IT organizations focus on the numbers in an SLA, and completely fail to meet their customers’ needs – even if they deliver the agreed numbers.
In this blog, I’ve offered a number of suggestions for how you can measure and report availability, but I haven’t discussed what you can do to help manage and improve availability. This is probably even more important, but it’s a topic for another blog.
It’s a long blog, so here are some of the key points that I’ve made within it:
- There’s little point in telling a customer that you provided 98% availability if you don’t understand the impact of the 2% downtime
- Talk to your customers to make sure you understand the business impact of any downtime on them, and on their end customers
- Think about ways to protect your customers’ critical business processes
- Find ways to measure the frequency and duration of downtime, and the impact of downtime on productivity that are matched to your customers’ needs
- Agree, document, and report availability metrics in ways that both make sense to your customers and help you to plan
- Use appropriate tools and instrumentation to help you measure and report availability.
What else would you add to my advice? Please comment below.
Stuart Rance is a consultant, trainer, and author with an international reputation as an expert in ITSM and information security. He was an author for ITIL® Practitioner Guidance, the lead author of RESILIA™: Cyber Resilience Best Practice, and the author of ITIL Service Transition, 2011 edition. He writes blogs and white papers for many organizations, including his own website.
Stuart is an examiner for ITIL, chief examiner for RESILIA, and an instructor for ITIL, CISSP and many other topics. He develops and delivers custom training courses, and delivers presentations on many topics, for events such as itSMF conferences and for private organizations.
In addition to his day job, he is also an ITSM.tools Associate Consultant.