Yup. And that's by design. Stability is asymptotic and increasingly expensive to reach toward 100%. There's a very intentional "this is good enough" point.
"The error budget stems from the observation that 100% is the wrong reliability target for basically everything
(pacemakers and anti-lock brakes being notable exceptions).
In general, for any software service or system, 100% is not
the right reliability target because no user can tell the
difference between a system being 100% available and 99.999% available.
There are many other systems in the path between
user and service (their laptop, their home WiFi, their ISP,
the power grid…) and those systems collectively are far less
than 99.999% available. Thus, the marginal difference
between 99.999% and 100% gets lost in the noise of other
unavailability, and the user receives no benefit from the
enormous effort required to add that last 0.001% of
availability.
If 100% is the wrong reliability target for a system, what,
then, is the right reliability target for the system? This
actually isn’t a technical question at all—it’s a product question.."
If I worked for YC as a HN mod I would literally spend a bit of time every day to review as many mono space-using comments I could every day and edit them to use > instead.
Then you would have that bit of time back, and the rest of us could stop scrolling back and forth when someone code-blocks a blockquote.
You want something separate for code blocks and block quotes here.
But seriously HN should just allow basic quotes. And, while they are at it, increase the size of voting arrows to make it possible to reliably hit them on mobile. I get it’s somewhat nice to have a site that does not constantly redesign everything, but pretending you lost the password for the server is just overdoing it in the opposite direction.
I was left satisfied when they added the unvote/undown buttons. I only miss on my first try about 10% of the time :)
At least I didn't accidentally Flag something today.
But for some reason, we HAVE TO tolerate software crapping itself once a year?
I don't accept this logic. This is just a sign of how sloppy the industry has become.
This is the reason your phone becomes obsolete after 2 years, whereas your car can continue to run after multiple decades of abuse.
Second: Air travel could be much, much cheaper if it didn’t have to be nearly 100% reliable. This would be the right trade-off to make in almost any application that doesn’t almost guarantee deaths when it fails.
For example, plenty of higher end cars in california come with summer tires that can't be used in cold weather/ice.
Even the brakes you are talking about must be replaced every X miles (depending on how new the car is, this may be between 10k and 50k miles)
Houses are not definitely designed to be 100% available. This is in fact why they fail due to fire or earthquake or other events. The design point is not instant failure, but it's also not "100% available".
Like the SRE book says, they make a tradeoff.
Gmail going down is like your car being in the shop. It's not equivalent to a plane crashing; the equivalent there would be the entire contents and history of your Gmail account being unrecoverably deleted, and you yourself had no backups. Of course, I'd still much rather have that happen a hundred times than be in one fatal plane crash ..
> [Google's infrastructure] delivers Gmail and other services to hundreds of millions of users with 99.978% availability and no scheduled downtime.
[1] https://support.google.com/googlecloud/answer/6056635?hl=en
PS. 99.978% availability translates as a downtime of ~ 2 hours/year total. Not bad! But it's when things break that we realize how performant and reliable they actually are.
Edits: various typos.
Google, I think I've only really noticed it offline once in the past 10 years or so. Not complaining at all.
It's not a good metaphor, even if it looks intriguing at first sight.
So, can we get to the level where unavailability is actually an unnoticeable noise? Yes, but definitely not the way Google does things. I'd generalize that Google is absolutely not the place to look for ideas on reliability.
To say Google is not the place to look for reliability is a pretty comical statement.
99.99999 is 3 seconds of downtime/year.
As you get beyond 5 nines, environmental factors begin to dominate (if the service is networked: network unavailability, if the service is onsite, power outages and weather) any reliability inherent in the service.
If you are into reliability you really shouldn't take Google seriously.
The argument is basically the following:
(1) Consider the claim that getting to 100% reliability is important.
(2) If the claim were true, then it would be important to go from 99.999999999999999% availability to 100%.
(3) That is obviously not important, so the claim must be false.
(4) Since we have shown that the best target value is not 100%, it must be some number x, with x < 100%.
Genuinely curious.
In the aerospace industry, to get that last percent of a percent, 2 completely independent implementations of everything are used. Then to get another decimal, you add 2 more implementations and a consensus algorithm. Then of course you add static/unit/api/integration/stress/fuzz test suits for each implementation. Then test the tests. Then have a human run each test as the "second implementation" of the CI system. And so on, and so on. Each new decimal "9" cost multiple time more in human resource alone.
Then take into account the "productivity loss" of all those process and you need yet more poeple to progress as fast. Adding more people to a project has a diminishing return. After a while you can spend the entire GDP of the world and you wont be able to add another availability decimal point.
And in a couple decades, when the world GDP is a bit higher, formal methods will become practical in real-life situations.