At this point, we have wordy definitions of SLI, SLO, and SLA. So, let’s walk through some history of the terms so far. We’ll also introduce a few more neologisms along the way.
Back in the late 1980s, data center uptime and Internet access were becoming more commercially visible.
Uptime Institute was founded during this time and became associated with the desirable traits of availability relating to various facilities-based service providers that underpinned a growing Internet and World Wide Web.
If you’ve ever heard the phrase “99% uptime,” then you know there is a remaining 1% that is not uptime. Saying the words
“not uptime” is cumbersome, so
the engineering term Error Budget is also used today in certain circles to convey the remaining 1% of the time that is not uptime.
Up to now, the S in our definition list has stood for service. Now, let’s assume services originate from a place (like a website) that we call a site.
At this point, you might be wondering where Site Reliability Engineering originated. Site Reliability Engineering is a neologism created by someone, but it might not be on NPR’s A Way With Words just yet. We’ll get to that next.
With technology cultural movements such as DevOps, there have been disciplines formed within organizations such as Google. Historically, Ben Treynor Sloss joined Google in 2003 and has shared some of the Site Reliability Engineering (SRE) stories during his career.
Of note, in 2007, the
Amazon S3 Service Level Agreement was first published. Of particular note, Service Credits represent a failure to reach the SLO. Service Credits mean that end-users would get a 10% to 25% credit if Amazon S3 could not reach specific Monthly Uptime Percentages (99.9-99% and below 99%, respectively).
- October 1, 2007
- June 1, 2013
- April 4, 2018
- December 31, 2018
- March 20, 2019
- May 1, 2019
- July 31, 2019
Generally, each updated expansion tier, functionality, availability, and reliability associated with S3 have resulted in service credits calculations updates.