In Part 1 of this series, we defined Recovery Time Objective and Recovery Point Objective.
In Part 2 we will introduce and define the role that Service Level Agreements play in the recovery process.
An SLA (Service Level Agreement) is a contract between the customer, end user, department, or organization and a service provider (could be internal technical staff or an outsourced entity) describing the availability of an application, infrastructure, or enterprise. Usually, there are mechanisms to ensure SLAs can be met and penalties outlined if they are not.
There are many parts to an SLA (Service Level Agreement) including but not limited to RTO/RPO, user accessibility, technical assistance or management of the application, and rollback or production stand up. For the purposes of this discussion, we will consider how an SLA influences application availability in the event of an unplanned outage.
Typically, an SLA encompasses both RTO and RPO. In many cases, SLAs reflect only RTO and assume RPO is zero. There might be an RTO component specifically called out in the SLA, but to be thorough, consider SLAs to include both RPO and RTO as shown in the figure below. Assume ‘Now’ indicates the present time, or the time of an outage.
Notice the additional time between the outer boundaries of RTO and RPO, and that they both reside inside the SLA.
SLAs (Service Level Agreements) can be enterprise-wide or application-specific. Sometimes multiple SLAs are determined for applications, departments or collections of applications, enterprises or departments, and so on. Regardless of how many layers of SLAs exist, the shorter the SLA the shorter the RPO and RTO, and the more costly hardware solutions become to ensure the SLA is attainable.
In addition to the above, some organizations employ the idea of an SLO, or Service Level Objective. SLOs usually exist between the collective RTO and RPO time, and that of the SLA. Or. One could argue that the SLO should be less than the RPO and RTO collective time. However you define it, the objective should be more aggressive than the agreement.
In Part 3, we will continue our explanation of RTO and RPO by discussing and analyzing an environment discovery process example.
If you have any questions or comments please feel free to reach out to our technical team today
Leave a Reply