Release It! - Chapter 13.2 Documenting Availability Requirements

Vagueness in SLAs aren't good for anybody, especially you.  Don't offer SLAs for the entire system, rather offer SLAs for discrete pieces of functionality.  Some are more important to the customer than others and are probably worth the expense of making them more available than others.  Remember that SLA inversion says you can't have SLAs any higher than worst SLA of your dependent systems. Availability needs to be defined, specifically how it is being tested.  An automated program generating synthetic transactions is better than humans randomly clicking around a UI.  Define the mechanisms used for checking availability and how the monitoring tools will report problems.  Consider defining the following for each SLA:

• How often will the monitoring device execute its synthetic transaction?
• What is the maximum acceptable response time for each step of the transaction?
• What response codes or text patterns indicate success? 
• What response codes or text patterns indicate failure? 
• How frequently should the synthetic transaction be executed?
• From how many locations?
• Where will the data be recorded?
• What formula will be used to compute the percentage availability? Based on time or number of samples?

It might also make sense to see if the customer requires integration with their own monitoring tools.