Talk:Myth of the nines
This article was nominated for deletion on June 29, 2006. The result of the discussion was keep. |
Inconvenient outages
[edit]"Another factor is that computer systems do actually tend to experience outages at the most inconvenient time, when the system is most heavily used." Source? Crid 07:36, 16 December 2005 (UTC)
- Murphy's law?
Seriously, though, it's rather obvious that systems under heavy load are more prone to failure than systems under light load, because heavy loads exercise boundaries of system tolerances (they run hotter, consume more memory, use more disk space, process many different inputs that may trigger pathological cases in software, etc.) Furthermore, a system under heavy load is most probably under heavy load because there's a lot of work to be done, so an outage at these times is more inconvenient than an outage at a time when the system is picking its nose.
Per Wikipedia:Guide to writing better articles#State the obvious, we could put a note in to this effect if this line of reasoning is not obvious. JRM · Talk 01:24, 22 December 2005 (UTC)- The insight is more implicit than obvious... The word "inconvenient" is what bugs me. Boolean logic is not concerned with what we feel is tolerable. Murphy's law is an attitude problem. But computer science is inherently technical and seems like black magic to many people. (That's why I got to this page.) So perhaps superstitious rhetoric should be avoided. Anybody who pursues 5 nines for a living is probably all about the real world. Anyway, I trust your judgment. Crid 01:24, 25 December 2005 (UTC)
- For completeness, the mention of Murphy's law wasn't supposed to be a rational explanation... I see what you mean, though, the sentence seems to appeal to a sort of mystic intuition about "how these things work" which is really not necessary; there are perfectly objective explanations for why systems fail at those times humans would consider most inconvenient.
- What's worse from a writer's point of view, however, is that the fact is irrelevant. It doesn't tie in with anything. It is not "another factor" (of what?), it's just a tidbit about subjective perception of failure. I've removed it on those grounds. JRM · Talk 00:31, 26 December 2005 (UTC)
- The insight is more implicit than obvious... The word "inconvenient" is what bugs me. Boolean logic is not concerned with what we feel is tolerable. Murphy's law is an attitude problem. But computer science is inherently technical and seems like black magic to many people. (That's why I got to this page.) So perhaps superstitious rhetoric should be avoided. Anybody who pursues 5 nines for a living is probably all about the real world. Anyway, I trust your judgment. Crid 01:24, 25 December 2005 (UTC)
What it means
[edit]delivering its service to the user 99.999% of the time it is needed.
No, no? I believe that 99.999% is a measure of the absolute number of minutes (or whatever) in a year; the phrasing we're using now isn't accurate for systems which must be usable as much as possible when the business is *not* in operation 24/7/365.25. --Baylink 18:13, 11 July 2006 (UTC)
Planned vs Unplanned downtime
[edit]I've heard someone say that contracts specifying nines of uptime typically exclude counting periods of "planned downtime", which could in fact extend into hours or days or longer as long as the outage is planned and scheduled. In such contracts, only "unplanned downtime" is usually considered to count against the alloted downtime. Can anyone else confirm this convention and maybe integrate into the article if this is indeed a common industry interpretation? -- Bovineone 20:59, 13 August 2006 (UTC)
The measurement is relative to expected available hours. If I promise to be available 7 hours a week, and I'm available 7 hours a week, I have 100% availability (I'm fulfilling the promise completely). Rational people recognise the need to allow for error, so the "nines" refers to the degree of error that's expected. The fewer hours you promise to be available, the easier it is to meet the goal - a few systems (like most phone systems, for instance) promise to be available all the time, and have a goal of meeting that promise 99.999% of the time. That is the assumption implicit in the "myth of the nines". But if you have a service level agreement with a hosting site that allows for them to be down on Sunday afternoons for maintenance, then you don't get to subtract Sunday afternoon service interruptions from their performance, as they didn't promise it in the agreement. Lesson: always read the fine print! -- not a user... —Preceding unsigned comment added by 199.90.35.11 (talk) 21:20, 29 May 2008 (UTC)
Mathematics
[edit]Just to note explicitly a trivial point when calculating probability. We've all implicitly used the approximation that:
(1 + x)^n = 1 + n.x #for small x.
This is a very accurate approximation, but its use should be noted.
Costs
[edit]I think a reference to the costs of a [Network outage] would be interesting. However, that article is currently in such a bad state that i do not want to add it here. And i do not have the necessary information to extend it. Dbu 13:50, 22 January 2007 (UTC)
Sales pitch
[edit]More often than not five & six nine availability figures are generously used by the sales and marketing teams to push a product. It is advised that buyers reconfirm as to how and what duration the system monitored before declaring these attributes to the given system.
There is nothing "mythical" about the nines
[edit]The calculation of the uptime as a percentage is widely used in SLAs so the article is providing some useful information.
I would like to add that there is no technical reason for it to be all nines. The expression of "five nines uptime" may be popular but you could express the uptime as 99.8% or 99.98% or whatever, albeit with less geek appeal.
Anyway, under the section entitled The myth explained the writer is confusing the technical issues with the business issues. There is nothing misleading or controversial about guaranteeing your uptime as a percentage and stating the remedies for failing to meet the guarantee. The collateral damage caused by downtime should be well understood by the customer, but the topic for such discussions should be "risk management", not uptime calculations.
As a service provider, it is not up to me to measure the impact that a system failure will have on individual customers. They are responsible for measuring that impact on their own businesses. I offer a percentage of uptime for a given price. They then decide if my guarantee is acceptable. If it is not, I can offer a higher percentage at a higher price. The guarantee is only one side of the equation, though. The other side is the remedies to the customer if I fail to meet the terms of my uptime guarantee. This should also be covered in the SLA.
I think the article should be renamed, removing the reference to "myth" and that subsection reworked, perhaps into something that examines the uses of uptime percentages in business risk management.
Further, I would like to see the article expanded to include more info concerning probability calculations. For example, I know that a single server with no redundancy will have a downtime of no less than 2 hours if the hard disk fails. (The presumption is that 2 hours is about how long it will take to replace the disk and restore from backups) But what's the probability that it will fail more than once a year? Or how do I calculate the uptime probability if I use use two servers in a cluster? Or three? That is the kind of information that I came to this article looking for but didn't find.
Stephen Brown 13:03, 20 April 2007 (UTC)
It's really awesome to calculate probabilities. It depends on whether the events are independent or not. Here, it depends if the servers act as full redundant backups for each other, or whether they are connected in full or part in a critical way. Let's assume that they are full redundant backups. If the uptime is 80% (it will illustrate things more clearly) on each server, then the probability of failure for each is .2. For the system to go down you will need both to fail concurrently. For this will multiply percentages 0.2 x 0.2 gives us 0.04 chance of failure which means 0.96 or 96% uptime. If we substitute 99.999% we get 99.99999999% (10 nines). This is a simple and idealised situation. If the systems are wholely dependent, for example in a cluster situation where the system will fail if any component server fails, then the opposite will occur. So for 80% uptime we need all our servers up for the system to be up, so 0.8 uptime for each server, and for three servers, 0.8 x 0.8 x 0.8, which gives 0.512 or 51.2% uptime for the system. Substituting 99.999% we get 99.99700003% (note above where small x etc). But if you need an article describing how to calculate probabilities, then I don't think this is the place.
For the other part, the chance of more than one failure in a year? We need more information than just the percentage uptime. We would need to know the average length of each downtime. But this gets a little tricky, because the downtime will be dependant on the component. A failed PSU in a hot swap box, might only take seconds to swap out and minutes for a reboot, but a failed CPU or mainboard will take longer to fix, particularly if you need to run diagnostics first. Given that each component will have different failure rates, and different associated downtimes, you need to add up a lot of numbers. But the 99.999% can't give you this info.
So in answer to the questions: this info isn't here because it don't have nothing to do with the article. 58.107.72.85 (talk) 00:21, 28 January 2008 (UTC)
One tenth as good
[edit]The article states: "For example, a system of ten components (eg. disks, motherboard, PSU, RAM, mains-power, network...), each with 99.999% availability, only has 99.99% overall availability (ie. one tenth as good)." This seems to be wrong. 99.99 isn't one tenth of 99.999. It's only one-thousandth less than 99.999. -18:23, 22 August 2007 (UTC)
- Subtract the percentages from 100% and you'll get it. 0.0001% is ten times less (failures) than 0.001% — so ten times better. -- intgr #%@! 21:15, 22 August 2007 (UTC)
- The fact is, that the overall availability is not equal to “one tenth” of something, the calculation uses tenth power (the resulting availability is 0.9999910), but the result is almost the same (~99.9900004+), because for small . --Mormegil 11:44, 26 October 2007 (UTC)
The Myth
[edit]I'm not convinced this is a myth. There are no references to back up the claim that "The myth of the nines is the implicit assumption that if the computer is operating 0.99999 of the time, then the user's business is operating 0.99999 of the time."
I notice the page Five nines redirects to this article. I would much rather have the content of this article moved to that page, and include explanatory notes about the implications or "false assumptions" about five nines. The encyclopedia is supposed to be factual and having an article about a supposed myth instead of spelling out the facts is not appropriate. Barrylb (talk) 09:22, 15 July 2008 (UTC)
- I am thinking of redirecting Five nines and similar articles to High availability which seems to cover the facts of the nines. Whether it is a myth can be dealt with separately here. Barrylb (talk) 09:26, 15 July 2008 (UTC)
On the "Matrix".
[edit]I propose that the following sentence be reworded. After an outage, the humans using the computer have to scramble to catch up, perhaps apologising to customers, calling them back, entering data written on paper during the outage, and other unfamiliar chores. If we are going to refer to ourselves in this manner, aren't we just asking for the computers to begin the usurpation? GuamIsGood (talk) 02:54, 14 October 2008 (UTC)
Wikiproject Computing
[edit]I have removed the WikiProject tag, as this article is either a redirect or deleted. If you oppose, please restore the tag. Thank you, fahadsadah (talk,contribs) 15:52, 30 March 2009 (UTC)