Live data from Hacker News

The August 17 outage

github.blog

411–420 of 804 posts

Re: The August 17 outage

#411

Earlier quoted context omitted.

I cannot even begin to express how many times I've seen engineers working super hard to optimize happy-paths so that we turn 3 nines of availability into 4 nines but introduce unintended emergent behaviors in unhappy-paths that turn 1 nine into zero nines via thundering herds, retry storms, etc.

You have my empathy for this kind of sentiment. Personally this seems somewhat rare in practice. That being said I'm curious if anyone has anecdotes they can share about these kinds of things?

Some anecdotes

1. People add retries w/o backoff. Now we have a retry storm.

2. People don't add jitter so we get huge waves of highly correlated retries that cause self-perpetuating overload cycles and failure.

3. People add retries (even w/ backoff) at more than one layer (e.g. one in process, one in envoy), so now we have a deeply confusing multi-level of retries with super weird n^2 patterns.

4. People find ways to fetch from multiple data sources to make a composite object but don't cache/reuse data they fetched, so one data source being down causes DOS on _other_ data sources because of retries.

5. People add failover mechanisms where all failures happily pick the same failover target because, ya know, it has the most free capacity.

6. People underestimate connection setup cost so "failover" causes huge increase in overall load due to connection setup (often tls setup) causing huge influx of "new" cpu work in a loaded system. CPU spike causes unhealthy destinations, causing more failovers, causing metastable failure.

7. People realize purely local decisions aren't optimal so add a layer of global health metrics (e.g. global retry budgets) but these systems add a time delay to the metric (ie its the view of the world 5ms ago). This delay makes their naive control algorithm go into oscillations or divergence spraying stuff everywhere.

All of these things have a similar pattern that when things are almost all good, they will make the system more robust. You'll get an extra 9 of reliability on good days. But they make everything far worse when things are bad.

Re: The August 17 outage

#412
post #132

> Errors in those services triggered a client-side retry loop that increased traffic during recovery Symptomic of a wider trend to avoid showing the user any error at all costs, even if that means they sit watching a spinner for 7 hours. > Delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified traffic by approximately 10x and caused delayed recovery for the Copilot Token…

"You can't seriously tell me that the unhappy leg of the code path has no test coverage." Sometimes I forget how ignorant HN can be of real world software development and the bar of corporate code quality, and then bangers like this remind me of it.

^ this lol, real world systems are so much more complex and involve much more coordination than a personal pet project. It’s so difficult to figure out the source of a bug in a production system like this.

Re: The August 17 outage

#413
post #89

Earlier quoted context omitted.

Is it impressive? All it's doing is decaying the services. 15 years ago never have imagined I would go to the lengths to host a github alternative on a VPS but after doing just this (also being the last one in the my professional group to do so), GitHub is giving a master class in destroying their reputation in pursuit of advocating for hostile entities. Not all growth is good, especially growth that is actively hurt…

This growth is surely good for github. If another company becomes the "github for AI agents", they'll lose not just their business for AI but also human coders. (Sure, maybe there will be a human coder only github, but it will be quite small.)

LLM companies are already wildly unprofitable. Who ever wants to do this can be my guest, but please let's tax them enough so that we can get something positive out of the stupidity like free public school lunches for children or universal childcare.

Re: The August 17 outage

#414

> Since April, monthly commits have grown from 1.4 billion to 2.9 billion Bonkers. You can tell the entire industry is in a "productivity panic" and here's more proof. There's a velocity zealot crying tears of joy somewhere.

Bonkers is right. Where in those ~12 billion commits is the software, products and "innovations" which are supposed to be making our lives better? Software and apps in particular are getting worse, normies hate AI more than ever because they're even less likely to get their desired outcome when calling their doctor or trying to get their online order refunded when chatting with a cutely named chatbot, wages for (most…

This comment comes up over and over again and it's incredibly ignorant.

To give just a single example, ai code dev has enabled people to make tools for themselves that they didn't have before.

I've made a language learning app for myself. Its working better than Duolingo so far, for me. Its not really public

Re: The August 17 outage

#415

Earlier quoted context omitted.

And 5K PRs. I'm crying.

> 5k PRs Wow, is Bun the record holder for number of PRs? I recall GitHub recommends to keep the number of PR to a certain level due things such as GitHub Actions slowing down.

You never could scale tulip buds so quickly - progress! ;-)

Re: The August 17 outage

#416

Earlier quoted context omitted.

The right answer is for the RPC framework to accurately communicate "try again on another node" vs "don't try again, just hard fail". When one end user request fans out to hundreds of backend requests (typical for microservices), you can't have each of those backend requests do its own exponential backoff. If they do it in parallel, they're a thundering herd, and if they do it in serial, the end user request will tim…

This is why you have circuit breakers upstream. Not on every individual instance.

In highly distributed microservice architecture, there's almost never a single upstream. In some cases you may have a couple of customer-facing entry-points (a global API gateway, and a couple of BFFs), but these are not the only paths that need to be protected.

There are client-side retries (which have broken GitHub in this case) and server-side initiated API calls between microservices that don't pass through any of your ingresses (e.g. triggered by an ETL pipeline, or a scheduled job).

With a complex architecture you can't just slap a circuit breaker on a couple of ingresses and call it a day. Don't get me wrong, putting them there does go a long way, but you won't be covering all your bases.

Re: The August 17 outage

#417

"Since April, monthly commits have grown from 1.4 billion to 2.9 billion. " Wow, that is some incredible growth in a really short time.

So much more stuff and growing- what it is actually useful for ? Are we getting actually more done than with previous volumes or is it just all wasted energy?

Re: The August 17 outage

#418
post #326

Earlier quoted context omitted.

That would just drive users into the arms of the alternatives, which would love to own the world's code... like Cursor/Musk. Microsoft and GitHub's only option is to suck it up, absorb this growth, and lower failure rates. They have the money, so that's not the issue. As someone on the sidelines, this is really interesting to watch unfold.

Why would any company want coding data now? It's all garbage. I'd be surprised if anything past 2025 is even used for training.

Me personally, I would like to own the world's code.

The richest man in the world is interested in this dataset as well.

Re: The August 17 outage

#419

"... these incidents make clear that we must accelerate this work." It feels like GitHub maybe needs to slow down? 'We must change things faster' is a wild way to start off an eight hour hard-down postmortem.

Do you think the load is going away? The current infrastructure cannot handle the new load requirements. Either the infrastructure must change, or they must start denying users the ability to use the infrastructure.

I may have come out with a different interpretation than you did of GP's comment. I see how you got to yours. But the way I read them saying they should slow down was, maybe slow down on new features. Which would mean they could shift resources from new features to infra.

Re: The August 17 outage

#420
post #414

Earlier quoted context omitted.

Bonkers is right. Where in those ~12 billion commits is the software, products and "innovations" which are supposed to be making our lives better? Software and apps in particular are getting worse, normies hate AI more than ever because they're even less likely to get their desired outcome when calling their doctor or trying to get their online order refunded when chatting with a cutely named chatbot, wages for (most…

This comment comes up over and over again and it's incredibly ignorant. To give just a single example, ai code dev has enabled people to make tools for themselves that they didn't have before. I've made a language learning app for myself. Its working better than Duolingo so far, for me. Its not really public

On the topic of translation/ language learning, I still find Google Translate better for when I need to type emails in Russian (my older family who only speak it) as far as grammar is concerned than what LLMs spit out.
Post reply on HN