I don’t think I understand your question. It depends on your SLA. If your SLA is a next business day response and you closed the ticket before 17:00 the next day, you were within your SLA so that is 100%. Are you asking if I have a spreadsheet that tells you for any given day, what the next business day is?

Sorry, but do you have any spredsheet to calc SLA ? For example: I Opened the ticket yesterday at 16:59PM and this ticket has closed today at 10:00AM anddd my SLA ir Worked days (08AM to 17PM)…By the way if you calculated this, you find the 3hours and 1 minut. All Rigth?! So can you help me with this please? If you don’t understand my problem, contact me please

Have a nice day! See you later!!!

Best Regards,

Raphael Teixeira

Excellent read for anyone embarking on system availability calculation.
Thanks for sharing.

I’m not sure I understand your question, although I’d really like to. I’d consider all IT systems non-deterministic, but there is enough determinism in the constituent components that when designed properly, you can have a reasonable chance at accurate prediction. You used the example of a private communication system deployed with scada. Under that scenario, you would estimate an expected availability (Not necesarily the SLA contracted for) to derive its impact on the total availability of the system. If its expected availability is not sufficient for the desired end result, you would then need to add redundancy, possibly with a second independant communication system.

So, let’s posit that we have a multi-site scada system, which uses MPLS to communicate under nominal operations. We have an SLA of 99.999% from the carrier, but we only believe it is likely to be 99% in the real world. We could then choose an alternate, such as a cellular system, that would take over if MPLS is down. It would be important to make sure the cellular system doesn’t rely on the same MPLS network, ie its with another carrier and uses different backhaul fiber. We would then estimate its availability also at 99%. This means that there is a small likelyhood that both systems will be down at the same time. This is the same calculation as equation #2 above and would give us 99.99% expected availability. If this isn’t enough, we might choose a 3rd option. It depends on the cost of downtime versus the cost to mitigate the expected risk. I hope this answers your question. If not, please restate it. Thanks for commenting!

mohamed eltahan

Excellent article. It really helped me to compute SLA on one of the new business opportunity, instantly.

Thanks!
- Neeraj

Thanks & Regards,
Katerinak.

For individual components you can measure their history, i.e. how many times di this server go down last year? If they are new, you make educated guesses based on experience, manufacturer specs, and overall design.

From the article: “Estimating availability can be a challenge. One method would be to look at historical data. If you don’t have access to good data, you can form an estimate based upon your standard operating parameters. For instance, if you release new code to your web server twice per month, and each release causes 2 hours of downtime, that would translate to 48 hours of downtime per year. If you expect to perform operating system maintenance once per quarter, at an estimated downtime of 2 hours per quarter, that would equal another 8 hours per year. If you also anticipate one hardware failure per year, and had a next business day warranty, that would translate to on average 41 hours of downtime per year (Friday outages get repaired on Monday. Saturday and Sunday outages get repaired on Tuesday). Adding these numbers up, we get: 48 + 8 + 41 = 98 hours of downtime per year, or an estimated 98.882% availability.”

-Bill

Thanks
Omar