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.
There are probably many such components; I'd imagine SRE alone would be 200+ people
How many of the remaining staff have the knowledge required to keep all of those components running smoothly?
You might have 200 different apps (hell, we have close to that, only 3 people in ops) but competent team will make sure they deploy in same way and are monitored in same way.
And once you go from "a server" to multiple servers, whether the end number ends up being 20 or 200 isn't that important till you start hitting say switching capacity, and if you're in cloud that's usually not your concern anyway.
Our biggest site (about dozen million users, a bunch of services and caching underneath, few gbits of traffic) took zero actual maintenance for 2022, "it just works", any job was implementing new stuff. It took some time to get to that state but once you do aside from hardware failures it "runs itself"
The SRE manager is in charge of keeping it all running. He isn't running around the world swapping out servers. He also isn't sitting back with his feet up thinking "All done - now how are my Pokemon doing?"
It's a dynamic process with quality monitoring, budgeting and reports, post-mortems, continual experiments to see if uptime can be improved, and redesigns as hardware and software change.
It's part of the backend, but is only loosely coupled to the content management and delivery system, the ad machine, moderation, marketing, and so on, all of which are going to have similarly complex structures.
Your car is working perfectly fine so why should you pay for maintenance?
In an organization of any appreciable size, things change all the time.. and I'm not just talking about code (for which you could have a code freeze in an emergency situation like this), but the external systems you're connected to could change for reasons completely out of your control. Content changes can break stuff because of bugs in your code. Legacy systems could require all sorts of ongoing tweaking and maintenance. And, yes, heat can break your software if the server it's running on overheats.
Twitter is not a palm_os app.
Your PalmOS app doesn't run on any modern hardware except under emulation. (Which is sad, I loved my Centro and held onto it for as long as I could.) The last release of PalmOS was in 2007, 15 years ago. Most hardware from that long ago is dead, and thus your software is dead. broken down by entropy to the hardware.
How many SSL certificates (internal or external) need re-issuing per month? Some of that can be automated, but in an organization as large as complex as Twitter some will be bespoke and manual, and a code freeze won't stop the clock.
How many new CVEs per month apply to Twitter's services and tooling? How many race conditions or other bugs are lurking, just waiting for the right time or traffic pattern to emerge? Twitter can't freeze inbound traffic without dire consequences.
Twitter is like your car, except that it's always running.
