Sorry - grammar eye twitch!
"Service Credit" means: (a) 10% of the total invoice charges for the affected month if the Monthly Uptime Percentage for any calendar month is between 99.0% and 99.9%; or (b) 25% of the total invoice charges for the affected month if the Monthly Uptime Percentage for any calendar month is between 99.0% and 95.0 %; or (c) 50% of the total invoice charges for the affected month if the Monthly Uptime Percentage for any calendar month is less than 95.0%.
Edit: It appears Microsoft/Office 365 offers the same SLA / 99.9%
One thing to keep in mind is that for each 9 of uptime you have, add about two Zeros to the budget and increase the timeline by one time units up and then double it. So if 99% costs you $100 and a day of timeline on the project, then 99.9% will cost you $10,000 and two weeks of timeline, and 99.99% will cost you $1,000,000 and 4 months of timeline, and 99.999% will cost you $100,000,000 and 8 years of timeline, etc.
It's more like going from the stone age to the bronze age. You need expertise and architecture suitable for achieving high availability, these are your budget increases, they are not linear at all. But the infrastructure itself doesn't necessarily get more expensive, on the contrary, new architecture could allow you to use the cheapest stuff available on the market.
At that point we only lose our issues list, etc.
just use git remotes
Which is to say that if I can get 75% of my work done without one of my tools then the impact to the business of an hours long outage is relatively small. Even if the outages are frequent, we can learn to adapt (real example: oversubscribed Atlassian products crashing on Friday afternoon due to resource exhaustion - move work to Thursdays or Mondays).
But if the entire system goes down due to shared hardware or simultaneous software upgrades, then you can end up with an office full of people who can't get a lick of work done. Heterogeneity wins out in this case, and 9's can be measured in a way that doesn't reflect the actual business impacts accurately.
Other than that, thirty minutes downtime 14 months ago when the public-facing redundant routers mis-detected a failover, failed STONITH and entered split-brain status.
I wouldn't commit to better than 99.9% with our infrastructure (single datacenter with remote data backups) but we exceed the metric most years (99.99% in all but one of the last ten years).
I can't recall the last unplanned outage since the 2008 one.
That was what kept me on GMail for so long. But about a month ago I moved several accounts to FastMail (at the urging of others on HN), and have been pleasantly surprised by the results.
FM seems to have a lot fewer false positives, and the amount of spam that gets through seems only marginally more than with GMail.
FM offers a 30-day free trial, which even includes using your own domain. That I found surprising. Usually trials so restricted you can't really get a sense of what you're getting into.
It doesn’t look like they’re doing much beyond what I did 10+ years ago when I was running high volume mail servers and it was never enough: https://www.fastmail.com/help/technical/spamchecks.html
Make the move away from Google, don’t be scared and don’t be guided by false excuses.
That's $500-$1000 a year on Fastmail's Standard plan, the lowest tier plan that allows you to use your own domain.
Im not really interested in managing everything that I perceive goes into managing my own email server (ip reputation management and having to keep a box online 24/7)
This myth that nobody but Gmail can handle spam needs to die. It was true in 2006, but it is not true in 2019.
The simultaneous fury and relief when we successfully logged users on the next day having made no functional changes was a watershed moment in our self-hosted services commitment.
Edit: actual status page says "significant subset of users": https://www.google.com/appsstatus#hl=en-GB&v=status
My money is either on that or the static content service.
> The browser connects to the HTTP server on this IP. This server (named the Google Frontend, or GFE) is a reverse proxy that terminates the TCP connection (2). The GFE looks up which service is required (web search, maps
Generally the availability of web services for individual users seems to be between 99.5 - 99.9 depending on the service.
Too high availability target wastes resources and network failures and third parties limit what actual effective availability can be.
"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
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.
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%.
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.
>Discussion| Please don't call "support numbers" posted below — most probably it's a scam. Make sure to report and "downvote" such posts.
However, I'm now worried that I might not be receiving email that I otherwise should be...
A while back Mozilla announced that they were migrating development to an independent team. I don't know much about that, but my impression as a user is that quality hasn't been affected and it might even be getting more love. I was happy to donate some money to the project last time they did a fundraiser.
The traditional whine: "But everybody uses HTML!"
text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html
auto_view text/html application/x-gunzip text/calendar
alternative_order text/plain text text/html application/postscript
mutt can be used as a pure IMAP client or to read local mail delivered to mboxes or maildirs.
If you are the sort of person who builds up 250,000 messages on your IMAP server, guess what: mutt handles it better than any other client.
mutt is not point and click. mutt is usable by people who can read, and is powerful for people who can spend twenty minutes reading the docs.
I'm the happiest I've ever been with email using that combination.
I've explained the basics of my setup before:
(Granted, I'm a heavy Emacs user, so I'm predisposed to like writing emails in Emacs.)
I previously used elm, mutt, sup, and probably a few other clients, but none of them felt as configurable and complete as my current set-up.
The calendar interfaces with your Google calendar too (with the Lightning and Provider for Google Calendar add-ons).
Available for Mac, Windows and Linux.
It has occasional quirks, but very stable.
Also, worth noting, most of these clients cannot handle Gmail's style of label handling.
If you feel like dealing with terminal based and text only email, I'm sure Mutt is fine. I'm not sure this is realistic for most people.
Evolution is a decent client with very minimal, basic features. It does allow handling of multiple email accounts but it didn't do a very good job of it. There are no plugins. It was often slow to perform actions like archiving or deleting (as if it did them in real time rather than in the background), which meant I couldn't quickly go through and process a list of emails. I had to pause between each action.
Geary was somewhat like Evolution but even more minimal. It has almost zero configuration options and no plugins. It's a very good looking email client, so if you have simple requirements and like the aesthetic it might be a good option.
Thunderbird was the most promising. A rich plugin ecosystem, better handling of multiple accounts. But it was buggy, a memory hog (6 GB RAM and 25% of my CPU when idling), and it would crash on me. There seems to be some history behind it that I didn't get into, but many plugins were not compatible with my version of Thunderbird. For example, I couldn't use the calendar because my version was too new. If critical plugins are going to be disabled any time I update the app, well, that's not worth dealing with to me.
Claws Mail was okay, even if dated looking. It had no contacts or calendar support. There were a few plugins but nothing like what Thunderbird offered. It had a few bugs, like when I switched folders it would scroll to random messages, and overall was too limited for my usage.
Mailspring is the best open source option I discovered. It's somewhat slow at times and can be buggy, but overall performed better for me than Thunderbird. It has some advanced features built in, handles Gmail labels perfectly, and is very clean looking. The biggest downside is that 1) it requires a Mailspring account (though it doesn't send your emails through Mailspring) and 2) is based off a monthly subscription (with a free option). In other words, you're generally dependent on the continuation of the Mailspring service for ongoing operation of your email client.
If open source is not a strict requirement and you are on Windows, Mailbird is the best email client I've ever used. It nails almost everything out of the box, is lightning fast, and has always been stable. If Mailspring doesn't work out for me I'm likely going to switch to using Mailbird in Wine.
Mailspring is not opensource, only the UI is.
Then again... Schrodinger's outage. Until everyone checks some people are not affected. Hence, never global. Right?
But honestly now, are you upset because of the semantics or because of the flatearther joke? ;)
> Hint: it's you
My comment may or may not be wrong but it was still on the topic of the article. I'll let you judge your own.
I mean, seriously? :)