<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Service-Level Agreements on Brave New Geek</title><link>https://bravenewgeek.com/tag/service-level-agreements/</link><description>Recent content in Service-Level Agreements on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 19 Feb 2024 14:21:05 -0700</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/service-level-agreements/index.xml" rel="self" type="application/rss+xml"/><item><title>Choosing Good SLIs</title><link>https://bravenewgeek.com/choosing-good-slis/</link><pubDate>Mon, 19 Feb 2024 14:11:17 -0700</pubDate><guid>https://bravenewgeek.com/choosing-good-slis/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2024/02/dashboard-1024x671.jpg"&gt;&lt;/p&gt;
&lt;p&gt;Transitioning from an on-prem environment to a cloud environment involves a lot of major shifts for organizations. One of those shifts is often around how we monitor the overall health of systems. The typical way to measure things like the availability, reliability, and performance of systems is with SLIs or &lt;a href="https://sre.google/sre-book/service-level-objectives/"&gt;Service Level Indicators&lt;/a&gt;. SLIs are a valuable tool both on-prem and in the cloud, but when it comes to the latter, I often see organizations carrying over some operational anti-patterns from their data center environment.&lt;/p&gt;</description></item><item><title>You Own Your Availability</title><link>https://bravenewgeek.com/you-own-your-availability/</link><pubDate>Tue, 22 Sep 2015 11:12:16 -0500</pubDate><guid>https://bravenewgeek.com/you-own-your-availability/</guid><description>&lt;p&gt;There’s been a lot of discussion around “availability” lately. It’s often trumpeted with phrases like “&lt;a href="http://www.whoownsmyavailability.com/"&gt;you own your availability&lt;/a&gt;,” meaning there is no buck-passing when it comes to service uptime. The &lt;a href="http://venturebeat.com/2015/09/20/amazons-aws-outage-takes-down-netflix-reddit-medium-and-more/"&gt;AWS outage&lt;/a&gt; earlier this week served as a stark reminder that, while owning your availability is a commendable ambition, for many it’s still largely owned by Amazon and the like.&lt;/p&gt;
&lt;p&gt;In order to “own” your availability, it’s important to first understand what “availability” really means. Within the context of distributed-systems theory, availability is usually discussed in relation to the &lt;a href="https://bravenewgeek.com/cap-and-the-illusion-of-choice/"&gt;CAP theorem&lt;/a&gt;. &lt;a href="https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf"&gt;Formally&lt;/a&gt;, CAP defines availability as a &lt;em&gt;liveness&lt;/em&gt; property: “every request received by a non-failing node in the system must result in a response.” This is a weak definition for two reasons. First, the proviso “every request received by a &lt;em&gt;non-failing&lt;/em&gt; node” means that a system in which &lt;em&gt;all&lt;/em&gt; nodes have failed is trivially available.  Second, Gilbert and Lynch stipulate no upper bound on latency, only that operations &lt;em&gt;eventually&lt;/em&gt; return a response. This means an operation could take weeks to complete and availability would not be violated.&lt;/p&gt;</description></item></channel></rss>