this post was submitted on 19 Nov 2025
361 points (98.4% liked)
Technology
76917 readers
3377 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So I work in the IT department of a pretty large company. One of the things that we do on a regular basis is staged updates, so we'll get a small number of computers and we'll update the software on them to the latest version or whatever. Then we leave it for about a week, and if the world doesn't end we update the software onto the next group and then the next and then the next until everything is upgraded. We don't just slap it onto production infrastructure and then go to the pub.
But apparently our standards are slightly higher than that of an international organisation who's whole purpose is cyber security.
You would do well to go read up on the 1990 AT&T long distance network collapse. A single line of changed code, rolled out months earlier, ultimately triggered what you might call these days a DDoS attack that took down all 114 long distance telephone switches in their global network. Over 50 million long distance calls were blocked in the 9 hours it took them to identify the cause and roll out a fix.
AT&T prided itself on the thoroughness of their testing & rollout strategy for any code changes. The bug that took them down was both timing-dependent and load-dependent, making it extremely difficult to test for, and required fairly specific real world conditions to trigger. That’s how it went unnoticed for months before it triggered.
Their motivation is that that file has to change rapidly to respond to threats. If a new botnet pops up and starts generating a lot of malicious traffic, they can't just let it run for a week
How about an hour? 10 minutes? Would have prevented this. I very much doubt that their service is so unstable and flimsy that they need to respond to stuff on such short notice. It would be worthless to their customers if that were true.
Restarting and running some automated tests on a server should not take more than 5 minutes.
5 minutes of uninterrupted DDoS traffic from a bot farm would be pretty bad.
5 hours of unintended downtime from an update is even worse.
Edited for those who didn’t get the original point.
It wasn’t an unintentional update though, it was an intentional update with a bug.
Edited. My point still stands.
Significantly better than several hours od most of the internet being down.
Maybe not updating bot mitigation fast enough would cause an even bigger outage. We don’t know from the outside.
There are technical solutions to this. You update half your servers, and then if they die you just disconnect them from the network while you fix them and then have your own unaffected servers take up the load. Now yes, this doesn't get a fixout quickly, but if you update kills your entire system, you're not going to get the fix out quickly anyway.
Congratulations, now your "good" servers are dead from the extra load and you also have a queue of shit to go through once you're back up, making the problem worse. Running a terabit-scale proxy network isn't exactly easy, the amount of moving parts interacting with each other is insane. I highly suggest reading some of their postmortems, they're usually really well written and very informative if you want to learn more about the failures they've encountered, the processes to handle them, and their immediate remediations
My assumption is that the pattern you describe is possible/doable on certain scales and in certain combinations of technologies. But doing this across a distributed system with as many nodes and as many different nodes as CloudFlare has, and still have a system that can be updated quickly (responding to DDOS attacks for example) is a lot harder.
If you really feel like you have a better solution please contact them and consult for them, the internet would thank you for it.
They know this, it's not like any of this is a revelation. But the company has been lazy and would rather just test in production because that's cheaper and most of the time perfectly fine.
It looks like you have never read their blog. They do a lot of research and upstream contributions to improve their stack