Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Major Service Outage

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: GitHub Major Service Outage

#61

Post by Arizhel »

alekratz wrote: post #42
JohnHaugeland wrote: post #32

feel free to make a better one

This is the biggest cop-out of a reply. I hate it. OP has already stated: >I pay them. My work pays them. Github is raking in oodles of cash and they STILL can't keep their service up without going down, quoted from OP, "[e]very couple months". It's not about "making a better one", nor is it about paying for the fancier/premium features; it's about the uninterrupted service, which Github keeps failing to provide.

I fail to see what the problem is. If you don't like their service, then switch to a competitor, or just set up your own git server. It's like this for any vendor: if you don't like the product or service you're getting, you can either bitch and complain endlessly, or you can look for alternatives. One of these choices is more productive than the other.

Re: GitHub Major Service Outage

#62

Post by peterwwillis »

toomuchtodo wrote: post #15
i336_ wrote: post #11

Earlier quoted context omitted.

I've noticed this behavior with a lot of services. I can only chalk it up to something like clock drift between the processing node and the database server. Irritatingly I can't remember which site it was but I posted something somewhere a couple days ago and immediately after hitting enter the site marked what I'd said as submitted "a few seconds from now". I never fail to be amused that the fuzzy time library being…

Message queues and eventual consistency. Unless your request requires something "atomicy", 200/201 response should be a sign of "got the message, will get to work on it when we can".

201 is "request has been fulfilled, resource has been created". It is explicitly not "we will get to it when we can". You are thinking of 202, "request has been accepted for processing", for asynchronous request processing.

Re: GitHub Major Service Outage

#63

Post by peterwwillis »

mhils wrote: post #28
runeks wrote: post #4

Good thinking on GitHub's part not using github.com/github/status to host the content of status.github.com. Amazon, take notice.

Nitpick: They would still fail for DNS issues with *.github.com, so a domain like githubstatus.com would be even more resilient.

Nitpick: www.githubstatus.com is more flexible, potentially more resilient.

Re: GitHub Major Service Outage

#64

Post by yeukhon »

Jayakumark wrote: post #23

A little funny like Silicon Valley episode , saw the news from GitHub CEO yesterday saying our goal is zero downtime and now it's down

You sure it isn't zero downtime deployment? But I thought Github runs infrastructure globally? I remember some outage were caused by DoDS, and some were software bugs / bad config.

Probably good idea to do rolling deployment. I will be surprised if they haven't for the kind of top engineering team they are running.

Re: GitHub Major Service Outage

#65

Post by wand3r »

JohnHaugeland wrote: post #32

feel free to make a better one

I think hindsight is 20/20. They obviously did not think they needed to find a competing service; nor build one as they were paying for one. Given that they have been inconvenienced by downtime they may switch or make their own.

> Feel free to make a better one

The GitLab team did that already so I use their service. ;)

Re: GitHub Major Service Outage

#66

Post by justinclift »

acdha wrote: post #57
edoceo wrote: post #35

Earlier quoted context omitted.

It's called GitLab. Not 100% uptime but better (and constantly improving)

Do you have data to support that claim about uptime?

GitLab's public service had a major outage a few months ago:

https://about.gitlab.com/2017/02/10/postmortem-of-database-o...

Re: GitHub Major Service Outage

#68

Post by aerovistae »

peterwwillis wrote: post #63
mhils wrote: post #28

Earlier quoted context omitted.

Nitpick: They would still fail for DNS issues with *.github.com, so a domain like githubstatus.com would be even more resilient.

Nitpick: www.githubstatus.com is more flexible, potentially more resilient.

Nitpick: www.statushub.com is less obviously related, and therefore won't be attacked in tandem. If they want to go all the way, maybe just something like www.wesellnikesdiscount.com.

Re: GitHub Major Service Outage

#69

Post by dromedary512 »

minxomat wrote: post #54
Xylakant wrote: post #39

Earlier quoted context omitted.

> I pay them. My work pays them. Hmm. You pay them to uphold a contract. What does that contract say about SLAs and availability? Probably the same as the TOS that I agreed to when paying and those specifically say: GitHub does not warrant that the Service will meet your requirements; that the Service will be uninterrupted, timely, secure, or error-free; that the information provided through the Service is accurate,…

Huh? You don't have to use Github Enterprise (self-hosted) to get an SLA. Github Business, which is hosted on github.com has a 99.95% uptime SLA: https://github.com/pricing An upgrade from Team to Business is "only" a 2.3x price bump per dev. I have no experience with this though, my team is still of the Team plan and thus suffered from the outage today.

Huh indeed. 99.95% uptime -- AKA: three and a half nines. My quick math tells me that 99.95% uptime equates to a downtime of ~4:23/yr. If github is down for an hour once every few months, I'd say they're likely well within their stated SLA.

Re: GitHub Major Service Outage

#70

Post by saosebastiao »

Business idea: github hosting failover. You'd probably need a modified git client, but if you can't push/pull/whatever from github, it transparently fails over to your service which will sync up with github once they've recovered.

Even better idea: github should stop failing.

Post reply on HN