HE.net, Fremont-2 outage?

Joe Greco jgreco at ns.sol.net
Thu Nov 5 13:49:47 UTC 2009


> Alex Rubenstein wrote:
> >> Yup.  Related: "100% availability" is a marketing person's dream; it
> >> sounds good in theory but is unattainable in practice, and is a
> >> reliable sign of non-100%-reliability.
> >
> > You are confusing two different things.
> >
> > Availability != Reliability.
> 
> Pardon the interruption...
> 
> In the aforementioned statement, there appears an intense/flagrant -
> compartmentalization/separation of terms without sufficient
> explanation. 

Correct.  It's even a bit more interesting than that; there's an
implication that marketing people will not really know the difference,
having heard repeatedly about "high availability", may proceed to
use "availability" as a buzzword...  I guess I was a bit more oblique
than intended.

> Note that in being available, 'a' criteria to ensure
> reliability is met.   If one has the desire to delve into some of the
> nuanced operational perspective, see: http://ow.ly/zmQg (pdf) or
> http://ow.ly/zmTB (web friendly).   The article is also available
> through the IEEE Portal at http://ow.ly/zn3a (if one of the other links
> appear to be unavailable, anytime).

I doubt marketing people will care.  :-)
 
> > For instance, an airplane is designed to be 100% reliable, but much less available. To keep a 747 from not crashing (100% reliability) it needs significant downtime (not 100% available).
> 
> This explanation, aside from being unsatisfactory, is misleading.  
> Operating times and maintenance times are very much separate quantities.

And airplanes aren't 100% reliable regardless...

For a power system as a whole, though, one could see 100% availability 
as a prereq for 100% reliability.  Of course, you more closely approach
100% through redundancies...  oops, should we introduce another term to
debate?  :-)

> >> And even for those who follow best practices...  You can inspect and
> >> maintain things until you're blue in the face.  One day a contractor
> >> will drop a wrench into a PDU or UPS or whatever and spectacular things
> >> will happen.
> >
> > That's were policies, procedures and methods come in (read: SAS70)
> 
> For the operationally minded -- on one hand, there is an assumption here
> that 'accidents' are not preventable;

You cannot eliminate accidents.  Accidents represent things which are by
definition unforeseen and unplanned.  Accidents may be reducible through
the use of good planning and practices.  On one hand, one can foresee a
risk in resting a wrench near some energized busbars while needing one's
hands to do something else; you can define good practices that forbid
this sort of thing.  Even that may not completely eliminate the practice;
there are plenty of examples of companies having good policies that are
disregarded by employees in the field.  On the other hand, when Bruno is
moving a construction excavator around next door, suffers a heart attack,
and floors the controls such that the excavator rams your building and
the boom arm penetrates your wall and shoves a guy face-first into the
busbars, well, obviously we're talking extremely unlikely (I hope it's
obvious I'm even trying to be a bit ridiculous), but that's an Accident.
And they happen.

> on the other hand, there is at
> least an assumption being made here that SAS 70 is the curative for
> 'accidents.'    To be brief, accounting for human behavior as an
> underlying contributor to accidents can be a backbreaking and immensely
> messy endeavor.   In this respect, SAS 70 can only be assistive.

Correct.  We can only hope to reduce accidents.

My original point was simply that I prefer people who recognize 100% as a
desirable-but-unobtainable goal.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.




More information about the NANOG mailing list