Live data from Hacker News

Why Twitter didn’t go down: From a real Twitter SRE

matthewtejo.substack.com

711–720 of 1001 posts

Re: Why Twitter didn’t go down: From a real Twitter SRE

#711
post #326

Earlier quoted context omitted.

John Carmack, "Elon is definitely an engineer. He is deeply involved with technical decisions at spacex and Tesla. He doesn’t write code or do CAD today, but he is perfectly capable of doing so." Kevin Watson, who developed the avionics for Falcon 9 and Dragon and previously managed the Advanced Computer Systems and Technologies Group within the Autonomous Systems Division at NASA's Jet Propulsion laboratory: "Elon i…

Elon also understands deep neural nets a lot more than I think people imagine. He starts with good intuitions and mental models, but also actively asks for technical deep dives, and has very good retention. E.g. I recall teaching him about our use of focal loss in contrast to binary cross-entropy for the object detection neural net (I said it had given us a 5% bump and he asked to know more) and he understood how it…

If that is the case, why has he been making mistakes that seem fairly elementary on Twitter? Like, I understand not understanding a problem space and wanting to learn more. But you say he has good intuitions and mental models–I would've expected at least some basic background research before posting online. Why aren't we seeing that?

Re: Why Twitter didn’t go down: From a real Twitter SRE

#712

Earlier quoted context omitted.

Argh. "It works now, so it will work until forever." It takes _effort_ to make it work this smoothly now, _and in the future_. SRE is about _preventing_ issues. Not mopping up after them. To me, the article read like every succesfull sysadmin story: there's no fires, so sysadmin must be bloat.

Whenever clients complain about those costs and efforts, i tell them it's just like their car. Your car is working perfectly fine so why should you pay for maintenance?

software doesn't break down from heat. An app I write today will run until the hardware dies. I have a palm_os app I wrote in 1998 that still runs perfectly.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#713

Earlier quoted context omitted.

Automotive and aerospace are not that similar to social media. People buying into the vision of "get the planet off fossil fuels for transport" and "get this species to Mars" are probably willing to make sacrifices that people working on social media are not. It's the Halo Effect fallacy to think competence in one field automatically translates to another. Especially when the founder in question has displayed increas…

> Automotive and aerospace are not that similar to social media. Yes. Social media is easier. > It's the Halo Effect fallacy to think competence in one field automatically translates to another. This is precisely about leveraging the Halo Effect fallacy. Elon Musk might not know social media, but the markets don't know that, nor do they care. The average retail trader sees "Elon Musk's company" and buys and holds, re…

Dealing with people is generally far harder than pretty much any engineering problem. The same is true of Twitter, because there are no easy answers or even clear goals.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#714
post #641

Earlier quoted context omitted.

No matter if it was or not and for better or worse: If Twitter survives this without any major harm it will have profound consequences for the whole software industry.

That's tiny bit of an exaggeration, maaaybe. Maybe completely prophetic, though! That said, Instagram was run by just a dozen people back then, while it had hundreds of millions of users, right? So it's not a new data point. Storing, retrieving, indexing, managing 280 char blobs (with links, threads, embeds) is not exactly the most hardcore of a problem domains. Microblogs are the typical tutorial topic, and twitter'…

Twitter is basically a real-time database where everything is interconnected. It's one of the harder things to scale because it doesn't allow for easy segmentation.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#715

Earlier quoted context omitted.

I think this is kind of baked in though. Part of the thought process seems to be, at least for non-paying customers, it's not actually necessary to have five nines for Twitter, because people will just put up with it if it's less reliable.

I don’t have personal experience in this, so obviously I can’t speak with any authority. But I have heard from colleagues that tons of little factors can dramatically affect user engagement. For example, even a couple dozen milliseconds of longer load times can push a noticeable number of users away from your app.

I have personal experience with this. The metrics (as much as I despise using them as a source of truth) undoubtedly show a very strong positive correlation between better load times and user retention.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#716

Earlier quoted context omitted.

Well, I think the issue is precisely considering Twitter a "simple technology project", and it's the same mistake that Musk does. Twitter isn't a "software and servers business" as he said. Twitter is a social community, and while in some regards it might be easier, it's also far more difficult in others. Just compare how many business and institutions can reliably launch rockets or create cars, and how many can reli…

> Well, I think the issue is precisely considering Twitter a "simple technology project" But I didn't call it "simple", I called it "simpler", and it is.

I think it's somewhat reductionist to call Twitter "simpler". The technical challenges faced by SpaceX, for example, are almost completely orthogonal to those faced by Twitter. Imagine swapping a random engineer at SpaceX with a random software engineer at Twitter -- do you think either would thrive in their new role?

Re: Why Twitter didn’t go down: From a real Twitter SRE

#717

Earlier quoted context omitted.

> As long as nothing changes, and you don't run out of disk space (from logs for example), things stay working pretty much just fine. > ... > There are other things that can bring a site down, like security issues, or bugs triggered by unusual states, too much traffic, etc. But generally speaking those things are rare and don't bring down an entire site. Aren't these changes inevitable, though? There is no such thing…

Software never goes stale, it's the environment around it which stales. Something from the 70s works perfectly fine, except it can't run on anything bare any longer, and the hard drives etc. have all long since failed or their PSU capacitors have blown....so Twitter will absolutely rot, how fast depends on several factors. I personally suspect the infrastructure used to build Twitter will rot faster than Twitter itse…

This assumes security doesn’t matter. You can’t run on stale code and be secure for too long, at least for anything non trivial. I imagine even if Twitter doesn’t add any functionality at so, it will still take hundreds of patches per Yasser.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#718

> This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I was partly expecting the rest of the article to explain to me why exactly it wasn't just bloat. But it goes on talking about this 1~3-person cache SRE team that built solid infra automation that's really resilient to both hardware and software failures. If anything, the article might actually…

And so is the cache setup. It’s permanently (and deliberately) running at less than 50% utilization to prevent an issue that comes up only once every 5 years (according to the author).

Re: Why Twitter didn’t go down: From a real Twitter SRE

#719

Earlier quoted context omitted.

> the article might actually persuade me that it was all bloat First of all, how does it persuade you of that? The article touches a really small (though incredibly important for up-time) subject. Secondly, in any large company, the majority is 'bloat'. It's security engineers, code reviews, data architecture, HR, internal audit teams, content moderators, ccrum masters and I can keep going. In a start-up many of thes…

> removing engineers won't instantly crash the product. It'll happen slowly It's amazing to me how many people following the Twitter saga, some familiar with or actually working in technology, thought that Twitter would crash within days of the engineers being fired. And because it didn't, the job cuts are justified.

> thought that Twitter would crash within days of the engineers being fired

Because they work for companies where the product would fail within days of them being fired themselves.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#720

Earlier quoted context omitted.

> absolutely bring a site down over time, is expired certs From today's Casey Newton's newsletter: In early December, a number of Twitter’s security certificates are set to expire — particularly those that power various back-end functions of the site. (“Certs,” as they are usually called, serve to reassure users that the website they are visiting is authentic. Without proper certs, a modern web browser will refuse to…

I can imagine both cases being true, that the renewal process is automated and that certs won't get renewed because institutional knowledge has left the door. Where I'm at, service-to-service TLS certificates (the bulk of our certs) are automatically rotated by our deploy systems. But there are always the edge cases: the certificates manually created a long time ago (predating any standardized monitoring systems) wit…

> the certificates manually created a long time ago (predating any standardized monitoring systems) with long expiry dates

Like the ever-popular "expires in 10 years" long-lived certificates. I've seen that happen: the VPN certificate, probably created by one of the founders 10 years ago when the company was tiny, expired one day without warning, breaking the VPN for all employees until it could be replaced (manually on every device).

Post reply on HN