外刊阅读20240810｜微软大宕机，暴露了什么问题？

+

上期划线句答案

+

本期内容

◆

双语阅读

It happened again: yet another cascading failure of technology. In recent years we've had internet blackouts, aviation-system debacles , and now a widespread outage due to an issue affecting Microsoft systems, which has grounded flights and disrupted a range of other businesses, including health-care providers, banks, and broadcasters .

Why are we so bad at preventing these? Fundamentally, because our technological systems are too complicated for anyone to fully understand. These are not computer programs built by a single individual; they are the work of many hands over the span of many years. They are the interaction of countless components that might have been designed in a specific way for reasons that no one remembers. Many of our systems involve massive numbers of computers, any one of which might malfunction and bring down all the rest. And many have millions of lines of computer code that no one entirely grasps.

We don’t appreciate any of this until things go wrong. We discover the fragility of our technological infrastructure only when it’s too late. So how can we make our systems fail less often? We need to get to know them better. The best way to do this, ironically, is to break them. Much as biologists irradiate bacteria to cause mutations that show us how the bacteria function, we can introduce errors into technologies to understand how they’re liable to fail. This work often falls to software-quality-assurance engineers, who test systems by throwing lots of different inputs at them. A popular programming joke illustrates the basic idea.

A software engineer walks into a bar. He orders a beer. Orders zero beers. Orders 99,999,999,999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd. (So far, so good. The bartender may not have been able to procure a lizard, but the bar is still standing.) A real customer walks in and asks where the bathroom is. The bar bursts into flames. Engineers can induce only so many errors. When something happens that they didn’t anticipate, the network breaks down.

So how can we expand the range of failures that systems are exposed to? As someone who studies complex systems, I have a few approaches. One is called “fuzzing.” Fuzzing is sort of like that engineer at the bar, but on steroids . It involves feeding huge amounts of randomly generated input into a software program to see how the program responds. If it doesn’t fail, then we can be more confident that it will survive the real and unpredictable world. The first Apple Macintosh was bolstered by a similar approach.