Live data from Hacker News

Post-Mortem for Google Compute Engine’s Global Outage on April 11

status.cloud.google.com

311–320 of 368 posts

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#311
post #20

Earlier quoted context omitted.

As long as the edge case bugs in self driving cars come up less frequently than human error, it's an overall improvement.

Currently, they don't. Google cars fail every 1,500 miles on average.

Where is that figure coming from? I'm curious what kinds of failures they have.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#312
post #157

Earlier quoted context omitted.

Cool plot line, I'd go see that movie. A related scenario, one that theoretically could happen today, is hacking into commercial airliners auto-pilot systems, and directing dozens of flights onto a target. Set aside the fantasy movie plot angle, how realistic is this today? Is it any more or less plausible than the millions of cars scenario? If people are truly concerned about the car scenario, shouldn't they be worr…

In the airplane case, it's possible today: https://m.youtube.com/watch?v=CXv1j3GbgLk And https://m.youtube.com/watch?v=Uy3nXXZgqmg TL;DR you simulate a bunch of other planes in close proximity and the auto-pilot freaks out and tries to avoid them. As the second talk explains, the pilots would definitely notice and switch autopilot off. This is why IMO it's very important to not take ultimate control away from humans…

No current airliner will automatically change course in response to a traffic conflict. If TCAS [0] gives an advisory, the pilot takes manual control or reprograms the autopilot. Spoofing transponder returns wouldn't do much to the aircraft except annoy the pilots.

Another reason traffic spoofing wouldn't cause the aircraft to deviate is that airliners fly standard approaches and departures (STAR [1] and SID [2]) and heavy traffic away from the approach paths would definitely get noticed.

Even the fly-by-wire Airbus can be flown manually using differential thrust and/or pitch trim control.

The only time I've heard of an Airbus loosing control of a damaged engine is when the electrical cable was physically severed. This was Qantas QF32 [1], after one engine exploded and damaged the cables to another engine.

To "take over" an aircraft with pilots in the cockpit, would require the compromise to multiple systems.

[0] https://en.wikipedia.org/wiki/Traffic_collision_avoidance_sy...

[1] https://en.wikipedia.org/wiki/Standard_terminal_arrival_rout...

[2] https://en.wikipedia.org/wiki/Standard_instrument_departure_...

[3] https://en.wikipedia.org/wiki/Qantas_Flight_32

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#313

TLDR; they simply didn't test their (global!) custom route announcement management software. An edge case was triggered in production, and they gee-whiz-automatically went offline. Epic fail. PS. To the downvoters, truth hurts.

Upvoted. I think they should put a soft version of this right on the first line, instead of burying it in an ocean of "harmless", "previously unseen" text dances.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#314

Earlier quoted context omitted.

Currently, they don't. Google cars fail every 1,500 miles on average.

Where is that figure coming from? I'm curious what kinds of failures they have.

https://news.ycombinator.com/item?id=11492569 <- I detailed it a bit more in this comment, including linking the source report from Google.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#315
post #6

Earlier quoted context omitted.

Yeah, remember, auto-pilot in a plane needs to be 100% reliable, or everyone dies. A car needs to be, I dunno, 80%? Compared to a bad human driver, who still drives every damn day, a computer need only be about 60% reliable to be better. People suck at driving. Even a shitty self-driving car will save a ton of lives simply by obeying traffic laws.

> Yeah, remember, auto-pilot in a plane needs to be 100% reliable, or everyone dies. First, they're not anywhere near 100% reliable. They can fail on their own, and they'll also intentionally shut themselves off if the instruments they rely on fail. https://en.wikipedia.org/wiki/Air_France_Flight_447 Second, an autopilot failure shouldn't lead to death if the pilots are competent and paying attention.

AF447 was a PILOT failure, not AUTOPILOT failure. The pilot didn't use proper stall recovery procedures, and put the aircraft into an unrecoverable stall.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#316
For the amount this cost them, they should have bought CloudFlare. If you play with [global BGP anycast] you are bound to get burned. This is not the first time that BGP took out your entire routing. This is probably not the last time that BPG will take out your entire routing. Whoever's job it was to watch the routing, I am sorry.

Pulling your own worldwide routes because you have too much automation; it will make a good story once it's filtered down a bit! Icarus was barely up in the air, too early for a fall.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#317
post #79

Earlier quoted context omitted.

What does a failed autopilot look like? Would a pilot do any better with an "aerodynamic stall"? I know little about planes and it seems like that'd be a big problem with or without a pilot driving.

All pilots are trained to recover from a stall. A failed autopilot could look like all sorts of things, from just automatically disconnecting itself (usually with a loud warning alert) to issuing incorrect instructions (which is why the pilots are supposed to be awake and alert while it's engaged, watching the instruments).

Actually a key finding in AF447 was that pilots were not trained on how to recognize and recover from a high altitude stall. It is not like flying a Cessna 150. The junior first officer didn't realize the aircraft had stalled.

Pilots were trained on the procedure for recovering from a low altitude stall; 100% or TOGA thrust and power out of it while minimizing altitude loss. Training has now changed for both low altitude and high altitude stall recovery.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#318

This is very interesting. From the little I understand (sorry for using AWS terms as I am more versed with AWS than GCE) this can happen to AWS as well right? even if your software is deployed to multiple AZs / multiple regions, if bad routing / network configuration makes it through the various protection mechanisms then basically no amount of redundancy can help if your service is part of the non functional IP bloc…

AWS dont attempt to do anycast, which is annoying but also means this can't happen

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#319

Earlier quoted context omitted.

Well No, There is an upper limit on the damage a bad driver can do by say crushing his car with a bus or something like that. Imagine a bug or malware triggered at the same moment world-wide. It could kill millions. So it not as simple as 'It just has to be better than a human'

I've been itching to release this terror movie plot into the wild: It's 2025 and more than 10% of the cars on the road in the US are self-driving. It's rush hour on a busy Friday afternoon in Washington, DC. Earlier that day, there'd been a handful of odd reports of self-driving Edsels (so as not to impugn an actual model) going haywire, and the NTSB has started its investigation. But then, at 430pm, highway patrol u…

You're over thinking it. Hack into onstar, brick every connected vehicle at hh:mm and have some gunmen start shooting at hh:mm + 1min.

Re: Post-Mortem for Google Compute Engine’s Global Outage on April 11

#320

> There are a number of lessons to be learned from this event -- for example, that the safeguard of a progressive rollout can be undone by a system designed to mask partial failures -- ... This is a really important point that should be more generally known. To quote Google's own "Paxos Made Live" paper, from 2007: > In closing we point out a challenge that we faced in testing our system for which we have no systemat…

The best example so far regarding fault tolerance. The Netflix Simian Army. Introduce failures constantly!

http://techblog.netflix.com/2011/07/netflix-simian-army.html

Post reply on HN