A properly specified SLA should be quite clear on those things. After all, isn't the whole point to come to an agreement about what you're providing, how to monitor it, and what constitutes a failure? Just throwing a number out (99.99%) as your "SLA" does not accomplish any of those goals.
-☙ Brian Mathis ❧- On Wed, Aug 10, 2011 at 12:53 AM, carlo <lo...@petalphile.com> wrote: > This may be irrelevant to some of you. > A former CTO once told me that SLA's don't mean shit. He meant it > inregards to getting refunds for SLA assurances in contracts, because one > can massage the SLA number (was our website up? was our api up? did you > get a 302 to a "scheduled maintenance" page instead of a timeout?) however > they'd like. > What I learned from that former CTO is that if you are concerned about SLA > in terms of a MBO or bonus, you can meet that $ by simply pointing out SLAs > don't mean shit. for the reasons above. keepalived, heartbeat, ELB, and/or > carp on *nix/cloud boxes meets this requirement if you massage the numbers > and failover scripts correctly. ;) > > On Tue, Aug 9, 2011 at 9:38 PM, Matt Simmons <standalone.sysad...@gmail.com> > wrote: >> >> Just for the record, I maintain that SLAs have absolutely no bearing on >> availability. They are contractual agreements that stipulate financial >> ramifications of excessive downtime. They do not have any magic effect of >> making the service more available. >> The very fact that SLAs exist means that they don't guarantee anything >> except for (usually small) financial compensation for the inevitable outage. >> >> That doesn't answer your question, but it's important to keep in mind, >> because a lot of people see an SLA of 99.999% uptime and think the service >> can go down for 5 minutes a year. >> --Matt >> >> >> >> On Mon, Aug 8, 2011 at 7:24 PM, Brian Mathis >> <brian.mathis+lo...@betteradmin.com> wrote: >>> >>> We all know, or at least have heard, that SLAs are very important, and >>> the more 9s you want the more expensive it gets. >>> >>> I'm curious about methodologies on how to figure out the requirements >>> and cost it takes to make sure you've achieved a certain level, >>> without going over. It's easy to think of ways to "make things >>> better", by adding redundancy, etc..., but how do you quantify what >>> you need to reach a certain level? >>> >>> >>> -☙ Brian Mathis ❧- >>> _______________________________________________ >>> Discuss mailing list >>> Discuss@lists.lopsa.org >>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss >>> This list provided by the League of Professional System Administrators >>> http://lopsa.org/ >> >> >> >> -- >> LITTLE GIRL: But which cookie will you eat FIRST? >> COOKIE MONSTER: Me think you have misconception of cookie-eating process. >> >> >> _______________________________________________ >> Discuss mailing list >> Discuss@lists.lopsa.org >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >> > > _______________________________________________ Discuss mailing list Discuss@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
