Why devops teams should eliminate SLAs
Service level agreements (SLAs) first became popular with fixed-line telecom companies in the late 1980s. For the last 20 years, billboards with five nines (99.999%) have peppered every interstate in major US metros. But are numbers of nines in an SLA the right metrics for how reliability should be communicated within an organization and externally to customers today?SLAs exist for a reason: lawyers. Anyone entering into a services contract needs a way out if the provider does not perform. [ Also on InfoWorld: Where site reliability engineering meets devops ] We all know the dance that happens with SLAs in contract cycles. The customer’s legal team (along with the procurement team) want as many guaranteed nines as possible, and the service provider’s operations staff want to hard commit to as few nines as possible. Usually, customers negotiate a clawback or credit for missed SLAs.To read this article in full, please click here
Service level agreements (SLAs) first became popular with fixed-line telecom companies in the late 1980s. For the last 20 years, billboards with five nines (99.999%) have peppered every interstate in major US metros. But are numbers of nines in an SLA the right metrics for how reliability should be communicated within an organization and externally to customers today?
SLAs exist for a reason: lawyers. Anyone entering into a services contract needs a way out if the provider does not perform.
We all know the dance that happens with SLAs in contract cycles. The customer’s legal team (along with the procurement team) want as many guaranteed nines as possible, and the service provider’s operations staff want to hard commit to as few nines as possible. Usually, customers negotiate a clawback or credit for missed SLAs.
