Home Tech Software’s Bad Batches: What the Great Outages Taught Us

Software’s Bad Batches: What the Great Outages Taught Us

by zoeyjames
An engineer working among racks in a data centre server room

It is now a genre of news event: a morning when the world’s systems fail together. Airline check-ins freeze, hospital screens blue, payment terminals die, and within hours the cause narrows to a single software update pushed overnight to millions of machines at once. The great outages of recent years — faulty security updates, broken cloud configurations, expired certificates — differ in detail but rhyme in structure, and our failure file keeps growing. Software has developed its own version of the bad batch: a defect shipped at planetary scale before anyone noticed it was defective.

The root pattern is concentration plus velocity. A handful of platforms now underpin everything, and their update pipelines are built to move fast — security patches, especially, are pushed globally within hours because the threats they fix are live. Speed is genuinely protective, until the patch itself is the threat. In the most infamous case, a content update to a widely deployed security sensor crashed the operating system kernel it lived in, and recovery required touching each machine physically — the reason airports took days, not hours, to unwind.

The Boring Practices That Prevent It

The remedies are unglamorous and well known: staged rollouts that send updates to one percent of machines before the world, canary deployments with automatic rollback, and the discipline to treat configuration changes with the same suspicion as code. Site reliability engineering, as documented in resources from Google’s SRE practice, institutionalises exactly this paranoia. Yet the economics push the other way — vendors compete on how fast they protect you, regulators demand rapid patching, and the staged rollout that would have caught the defect reads, on every normal day, as unnecessary delay. The outage is the invoice for all the days the shortcut worked.

Resilience Is a Design Choice

The organisations that recovered fastest shared a trait: they had practised being broken. Their systems degraded gracefully, their staff had manual fallbacks, and their dependencies were mapped before they were tested by reality. For the rest of us, the lesson is smaller but real — the modern world’s software is a monoculture of a few platforms, and monocultures fail together. Diversity, staging and rehearsed recovery are not nostalgia for a simpler era. They are what engineering maturity looks like when a single bad batch can stop the planet before breakfast.

For individuals, the outages taught a smaller, practical curriculum: keep some cash, keep offline copies of what you cannot afford to lose access to, and be suspicious of any system — including your own phone’s update settings — that changes everything at once without asking. None of this is Luddism. It is the household version of staged rollout: never let a single update, document or device become a single point of failure for a life. The planet learned that lesson at the scale of airports. It scales down to a wallet surprisingly well.

You may also like

Leave a Comment

Notice: Paid content may appear on this website. Not all submissions are checked daily. The owner does not endorse or support illegal activities like gambling, betting, casinos, or CBD.

Close Welcome Bar