Talk:High availability

Renaming this article?

For what i read here it is a (computing) type of article, completely centered around the specific use of the term "high availability" in computer world. However i find much of what is written here could be perfectly valid for Mass Transportation Systems (like elevators and escalators) as well as for uncountable industrial systems. Would it be best to rename the article and create another (more general)one using it as a base? Or should then this article be reshaped a little?

(just wanted to discuss it before being bold...) Helsinkijaui 10:11, 25 September 2007 (UTC)

Is the term commonly used for those systems also, or just that it could be used? In either case, I'm suggesting (below) to merge this article into the one on availability; I'm not sure how that might interact with your suggestion. NathanWalther 17:41, 5 November 2007 (UTC)

I added generic coverage of high availability as it applies to redundancy in complex systems. Nanoatzin (talk) 11:52, 28 January 2011 (UTC)

Merge into Availability?

I think "high availability" should just be a section of a discussion on availability. Any objections to merging this article into Availability?

NathanWalther 17:36, 5 November 2007 (UTC)

High availability systems are basically an entirely separate set of computer systems; they have either at least on redundancy per choke point, or sometimes two. Some high availability systems are two of the exact same hardware, with one set to kick in if one fails. this is fairly separate from just availability. I suggest to leave it. —Preceding unsigned comment added by 173.48.59.243 (talk) 19:21, 16 March 2010 (UTC)

This article is an article on high availability in computing, and as such, I'm going to make some changes to make it clear that this is specific to computing. It would require a lot of work to merge into a general availability article, but it could probably be done. 70.250.239.119 (talk) 02:51, 26 August 2010 (UTC)

Myth of the Nines

Redirected from Myth of the Nines ? Someone who doesn't know what the myth of the nines is (and I only have a rough idea) would be totally confused. Kestasjk (talk) 12:42, 13 August 2009 (UTC)

You can add redirects yourself. Just click that red link and put #REDIRECT High availability on the page. Unfortunately, this article does not address the subject of the Myth of the Nines itself though Google's #1 hit in this article.^[1]. --Marc Kupper|talk 15:35, 13 August 2009 (UTC)

Right, that's the problem. Not that it doesn't redirect but it should, but that it does redirect and it shouldn't. Kestasjk (talk) 04:34, 17 March 2010 (UTC)

I've redirected it to the existing article on nines; that, presumably is best. 70.250.239.119 (talk) 03:00, 26 August 2010 (UTC)

System availibilty vs computer system avalibility

True high avalibility systems extend beyond the computers (hardware, software, networks etc), and includes the people, processes and procedures. Where the system is avalible, but running at less than ideal performace the systems still provide degraded availibilty, to the extreme where the process and procedures provide a service with no running computer systems. EFTPOS is an example - a manual paper based process can be used when the computers or networks fail, meaning the customer can still make use of the system.

The artical is overly simplistic and fails to consider that high reliablilty does not come from reliable components- contary to what the artical states, once a system has achieved true high reliabilty, unreliable individual components are no longer a risk to the system as a whole. For instance, computing hardware in Airtraffic control systems sold today (by the two largest manufacturers) is COTs hardware and LINUX OS and many Open Source components, yet provide some of the most reliable systems in the world. —Preceding unsigned comment added by 203.109.220.36 (talk) 08:39, 21 September 2010 (UTC)

Pipeline PDF Is Referentially Circular

This PDF seems somewhat informative, but there is at least one circular reference, as it points back to Wikipedia, and at a #REDIRECT page at that. It's also not particularly well-written. I personally stopped reading it at about the 4th or 5th bad spelling and 3rd or so bad capitalization. I suppose you could call it a quirk of mine, but I find it too distracting to read on after a few errors like this. -- Joe (talk) 03:53, 23 November 2010 (UTC)

 Done: went ahead and removed it, since no one defended it in 3 years. --M4gnum0n (talk) 15:07, 5 December 2013 (UTC)

Missing table

In percentage calculation: "The following table shows the downtime that will be allowed for a particular percentage of availability, presuming that the system is required to operate continuously.". Either the table was never written or an edit has removed the table. Can someone please create or bring back the table? --72.211.147.156 (talk) 19:55, 1 September 2012 (UTC)

9 Fives

LOL ARosa (talk) 23:19, 27 November 2012 (UTC)

Costs of Unavailability

I think the idea of quantifying the impact here is important, but I doubt the validity of quoting a study from 1996 on the impact of system availability. In 96 ecommerce and eBusiness were marketing concepts that had yet to be fully realized. Yes, there were large business systems and wide use of interconnected technology, but the interdependence of systems that we have today was barely imagined. — Preceding unsigned comment added by 115.85.30.58 (talk) 10:25, 11 December 2012 (UTC)

A vote of confidence

This is an area I know quite a bit about - IT systems and high availability - in my professional capacity, and while there's a bit of jargon here and there, overall, this is an admirable, high-level, non-technical discussion of the concept and what's important about it as it relates to information systems. FWIW high availability as a term of art is singular to the IT industry even tho similar concepts apply everywhere, from the Space Shuttle's famous redundancy systems to railroad schedules and power delivery grids. This wiki article is accessible, correct and relevant pretty much as is, and the statistical charts on uptime percentages are great. I would leave this alone unless it turns out to have been plagiarized, even though the references are pretty bunk.146.115.156.66 (talk) 17:46, 2 January 2013 (UTC)

Merge from Class of 9s

This article currently duplicates most of Class of 9s, and I see very little scope for that article to be expanded usefully. As such, I'm proposing that article be merged into this one. —me_and 16:51, 11 March 2013 (UTC)

I agree. It really doesn't stand on its own - it's a component of availability - and I agree it makes the most sense to combine them. Keithh (talk) 22:14, 15 March 2013 (UTC)

- I agree as well. - network tech, USA — Preceding unsigned comment added by 68.11.90.163 (talk) 23:04, 23 March 2013 (UTC)

Merge from Nines (engineering)

As with the above merge proposal, Nines (engineering) doesn't contain anything that wouldn't fit perfectly well into this article. As such, I'm proposing that article be merged into this one in the same manner as Class of 9s.

I don't think it makes any difference, but I'm noting it here for clarity anyway: there was a previous proposal to merge Nines (engineering) into Class of 9s last August/September. The only two accounts to comment there have both been blocked indefinitely as being sockpuppets of Gamsbart. As such, I think that discussion should be considered null and void. My confusion over what happened there is the reason I didn't propose both merges at once.

—me_and 19:07, 25 March 2013 (UTC)

Leave it as is

High availability is more than only IT-industry jargon. It comes from network theory/telecommunication, e.g. phone lines or fly-by-wire controls. The article at hand doesn't very much cover these aspects (albeit its general reference to system design) nor does it very much touch upon the OSI/ISO model. Now. percentage calculation can always apply, but it is chiefly the (professional data centre) IT industry that makes use of the "Class of 9s". In so far, it becomes more specific, thus justifying an article of its own. So, to leave the articles as they are shall be preferable. LordZebedee (talk) 10:34, 2 June 2013 (UTC)

outdated?

No info here defending the "outdated" tag - removing it. — Preceding unsigned comment added by 24.21.184.189 (talk) 04:30, 23 February 2014 (UTC)

Percentage calculation table issues

The table in the Percentage calculation section has had columns and rows added over the years. Unfortunately, the editors doing this seemed to have used different definitions for the number of days in a year each time they made an addition. The downtime per year column used 365 day years for most values other than the 97% row which used a 365.25 day year. The downtime per month column used a 360 day accounting year for most rows other than 99.8% and 99.95% which used a 359.3 day year and the three nines plus four nines rows used either a 365 or 365.25 day year (the results are the same as whoever added it rounded the values). The rows for eight and nine nines used a 365.24219 day mean tropical year. In other words, there was no consistency from one row or column to the next. The per week and per day columns were okay as those do not depend on the length of the year.

I have seen Service level agreements define the year as

• 360 days or 31,104,000 seconds/year defined on 360-day calendar.
• 365 days or 31,536,000 seconds/year which is defined in ISO 80000-3.
• 365.24219 days or 31,556,925.216 seconds/year in a mean tropical year.
• 365.25 days or 31,557,600 seconds/year which is a Julian year (astronomy).
• 366 days or 31,622,400 seconds/year which is defined in ISO 80000-3.

I recomputed all of the table values using 365.25 days or 31,557,600 seconds per year. --Marc Kupper|talk 07:41, 20 May 2018 (UTC)

I'm sad about the removal of "five nines" from the table

By @Jordan Brown in Special:Diff/887838908. It's a fairly common joke among those who deal with high availability, but unfortunately it doesn't seem to have often made it to print. I found a few passing references, but nothing directly addressing the term.

• Newman, David; Snyder, Joel; Thayer, Rodney (2012-06-24). "Crying Wolf: False alarms hide attacks". Network World. Vol. 19, no. 25. p. 60. Retrieved 2019-03-15. – "leading to crashes and uptime numbers closer to nine fives than to five nines."
• Metcalfe, Bob (2001-04-02). "After 35 years of technology crusades, Bob Metcalfe rides off into the sunset". ITworld. Retrieved 2019-03-15. – "and five nines (not nine fives) of reliability"
• Pilgrim, Jim (2010-10-20). "Goodbye Five 9s". Clearfield, Inc. Retrieved 2019-03-15. – "but it seems to me we are moving closer to 9-5s (55.5555555%) in network reliability rather than 5-9s"

I also found [typo] where someone wrote "nine fives" when they meant "five nines". Despite WP:NOTJOKE, I don't think a little passing humor (that people who work in the area would immediately recognize and appreciate) is out of place. Anomie⚔ 12:32, 15 March 2019 (UTC)

I don't feel all that strongly about it, and wouldn't fight if you put it back. Jordan Brown (talk) 19:31, 15 March 2019 (UTC)

I would support removing it. I can't find any references to "five nines" in scholarly sources, whereas other uptime targets are thoroughly covered. — BillHPike (talk, contribs) 17:07, 17 April 2019 (UTC)

It's clearly not a target... it's a sarcastic reference to totally failing to meet any reasonable target. Jordan Brown (talk)

and when I added that I got the sense backwards in the edit summary; it is of course nine fives that is an anti-target. Sigh. Jordan Brown (talk) 01:12, 22 April 2019 (UTC)

Unless this specific element of sarcasm is given significant weight in reliable sources, it does not belong in the article. — BillHPike (talk, contribs) 02:21, 3 May 2019 (UTC)

As someone not particularly familiar with HA, the "nine fives" confused me enough that I had to stop reading the article and search Google for what applications that could possibly be for. And, of course, upon searching for that, I was only led to typos and -- unsurprisingly -- this article. I don't mean to be a party pooper, but I don't think the sarcasm is apparent to the target audience: people who are unfamiliar with the subject. Forresthopkinsa (talk) 19:49, 24 April 2019 (UTC)

I love it! 101.98.118.234 (talk) 21:01, 29 August 2019 (UTC)

Thank you for the careful references Anomie, and for being understanding Jordan Brown! I have:

• Added a mention of it in the prose of the "Nines" section (Special:Diff/1044962360).
• Amended the wording to user Jordan Brown's (Special:Diff/1044962663).

I think this strikes the right balance: it's funny but confusing to put in the table (as Forresthopkinsa notes), since it's not a real target (especially not as the first line in the table!). However, it is worth mentioning, owing to its common use, and because (as sarcasm) it's otherwise confusing, if not spelled out.

—Nils von Barth (nbarth) (talk) 01:16, 18 September 2021 (UTC)

+1 Forresthopkinsa (talk) 19:48, 7 March 2022 (UTC)

Reasons for unavailability needs refresh

The article is not clear on the order of importance (ascending/descending), and the source material linked is no longer available at the link. No discussion of the merit of the survey or methods was given, nor the number of individuals surveyed.

Several of the listed items are a bit vague, and are not particularly helpful. Reading aloud "Not following best practices in..." then the listed item shows how little meaning it has. "Not following best practices in Operations" for example. Operations is such a large, blanket term it might as well not be on the list, as it can really be taken to refer to the business as a whole. "What's the problem here?" "The business as a whole wasn't following best practices." "Oh, that really narrows things down. Thanks!"

A book on the factors themselves published in 2003... Neat. Thanks? Shouldn't that be listed in the "See also" section?

Overall a list that's 10 years old and has incredibly vague terms with no methodology really doesn't belong here. Also, the whole thing is just a bunch of opinions unless there's an actual documented article outlining what EXACTLY "Best Practice" is. Without a reference to "Best Practice" it's essentially just someone saying "You missed a spot" after you've been cleaning a 40 room mansion. PaulTM 0 (talk) 13:42, 28 August 2019 (UTC)

Merge from Resilience (network)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

To merge Resilience (network) into High availability, on the grounds of short text and context. Direction determined by the commonest search. Klbrain (talk) 10:51, 26 August 2023 (UTC)

---

High availability is arguably the term most frequently associated with this concept in networking. The Resilience (network) content can be presented as a subsection here. ~Kvng (talk) 15:27, 24 October 2022 (UTC)

"High availability" seems like a subtopic of network resilience, rather than the other way around, based on a quick Google Books search.[2][3][4][5]. DFlhb (talk) 13:56, 14 January 2023 (UTC)

Support merge in reverse direction. Resilience (network) is the broader topic, and even though it is currently the shorter page, it should be the target. Much of the material on High availability would be better placed under Resilience (network) anyway. Klbrain (talk) 10:32, 16 July 2023 (UTC)

One thing I've just noticed, which I'm very concerned about, is that this article gets 16k monthly views, while Resilience gets 500 monthly views. From experience, I'm confident the views wouldn't transfer over if reverse-merged, since Wikipedia's search is bad enough that the "merge target" article often won't show up in the search suggestions until you've typed the full name of the redirect. Regardless of what the broader topic is, this is the most recognizable term by far, so I now think Kvng's original suggestion was the right one. DFlhb (talk) 10:59, 16 July 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  Y Merger complete. Klbrain (talk) 10:51, 26 August 2023 (UTC)