In this video, we walk through 5 ISC practice questions on measures of system availability. These questions are from ISC content area 1 on the AICPA CPA exam blueprints: Information Systems and Data Management.
The best way to use this video is to pause each time we get to a new question in the video, and then make your own attempt at the question before watching us go through it.
Measures of System Availability
When a business depends on a system, it needs a way to measure how well that system is actually delivering. Availability measures do that. They are all built on the same starting point, which is the time the system is supposed to be running.
Agreed Service Time
Agreed service time is the set of hours a system is required to run. It is based on what the business needs, not on the clock. A customer-facing website may need to run 24 hours a day, every day. An internal payroll system may only need to run from 7:00 a.m. to 7:00 p.m. on weekdays.
For that payroll system, a month with 22 business days has an agreed service time of 12 × 22 = 264 hours, not the 720 hours in a 30-day month. Every other availability measure is calculated against this number.
When a service provider hosts a system, the service level agreement (SLA) usually guarantees a minimum uptime percentage. That percentage applies to the agreed service time:
Allowed downtime = agreed service time × (1 − SLA uptime %)
Suppose the payroll system’s SLA guarantees 99.5% uptime. The provider can allow 264 × 0.005 = 1.32 hours of downtime, about 79 minutes, before it is in breach.
Downtime
Downtime is any time within the agreed service time when the system isn’t available. The reason for the outage doesn’t matter. A planned maintenance window and an unexpected crash both leave users without the system, so both count.
What does matter is when the outage happens. Only the portion that falls inside the agreed service time counts. Here’s how that plays out for the payroll system:
- It goes down from 6:00 p.m. to 8:00 p.m. on a Wednesday. Only the hour before 7:00 p.m. counts.
- It is upgraded on a Saturday. None of that time counts, because the system isn’t required to run on weekends.
The same outage can count in full against a system that runs 24/7 and barely count against one with a shorter window.
Availability
Availability compares the service a system actually delivered to the service it was supposed to deliver:
Availability = ((agreed service time − downtime) / agreed service time) × 100
If the payroll system had 3 hours of downtime in a 264-hour month, its availability was (261 / 264) × 100 = 98.86%. Measured against a full 720-hour month instead, the same 3 hours would show 99.58%. That overstates availability, because it counts hours the system was never required to run.
A system with a short service window has fewer hours to absorb an outage. Each hour of downtime therefore pulls its availability down further than it would for a system that runs around the clock.
Mean Time Between Failures
Mean time between failures (MTBF) measures how long a system typically runs before it fails:
MTBF = total operational time / number of failures
Operational time is agreed service time minus downtime. Suppose a server must run 24/7 for 30 days (720 hours), fails 4 times, and is down a total of 20 hours. It operated for 700 hours, so its MTBF is 700 / 4 = 175 hours.
A higher MTBF means the system fails less often, which makes it the more reliable system. MTBF is about how often failures happen, not how long they last. A system with a lot of total downtime spread across only a few failures can have a higher MTBF than one that fails often but recovers quickly.
Mean Time to Repair
Mean time to repair (MTTR) measures how long it typically takes to restore a system after it fails:
MTTR = total downtime / number of failures
For the same server, MTTR is 20 / 4 = 5 hours. A lower MTTR means the organization gets the system back up faster.
MTBF and MTTR describe different things. MTBF reflects how often a system breaks, and MTTR reflects how well failures are handled once they happen. Because MTTR is an average, multiplying it by the number of failures gives back total downtime, which can then be used to calculate availability.
