Live data from Hacker News

An update on Sunday’s service disruption

cloud.google.com

211–220 of 220 posts

Re: An update on Sunday’s service disruption

#211

Earlier quoted context omitted.

Don't think of it as "config". Think of it as input, to a global network of inter-dependent distributed decentralized programs, which control other programs, that then change inputs, that change the programs again, and which are never "off", but always just shifting where bits are. Imagine a cloud-based web application. You've got your app code, and let's say an embedded HTTP server. The code needs to run somewhere,…

Sure I think that’s a good way to think of it. When you do, it seems odd that you’d accept the possibility of inputs that can stop the entire system working to the extent that no new inputs can be tried for hours. In retrospect, that’s a mistake. There are other ways to control change and limit breakage other than just tests - dev networks at smaller scale, canaries, truly segregated networks, truly separate control…

> We would not accept a program that rewrites itself in response to myriad inputs and is therefore highly unpredictable and unreliable, and config/infrastructure should be held to the same standard.

Fwiw, that's what web browsers do; they download code that generates code and runs it, and every request-response has different variables that result in different outcomes.

And again, it's really not "config", it's input to a distributed system. It's not "infrastructure", it's a network of distributed applications. These can be developed to a high standard, but you need people with PhDs using Matlab to generate code with all the fail-safes for all the conditions that have been mapped out and simulated. Writing all that software is extremely expensive and time-consuming. In the end, nobody's going to hire people with PhDs to spend 3 years to develop fool-proof software just to change what S3 bucket an app's code is stored in. We have shitty tools and we do what we can with them.

Let's take it further, and compare it to road infrastructure. A road is very complex! The qualities of the environment and the construction of the road directly affect the conditions that can result in traffic collisions, bridge collapse, sink holes. But we don't hire material scientists and mechanical engineers to design and implement every road we build (or at least, it doesn't seem that way from the roads I've seen). You also need to constantly monitor the road to prevent disrepair. But we don't do that, and over time, poor maintenance results in them falling apart. But the roads work "well enough" for most cases.

Over time we improve the best practices of how we build roads, and they get better, just like our systems do. Our roads were dirt and cobblestone, and now they're asphalt and concrete. We've switched from having smaller, centralized services to larger, more decentralized ones. These advances in technology mean more complexity, which leads to more failure. Over time we'll improve the practice of running these things, but for now they're good enough.

Re: An update on Sunday’s service disruption

#212
post #138

Earlier quoted context omitted.

What can prevent this from happening in the future? Why was the config change required?

Test changes on smaller parts of the network before pushing them to critical parts would be a first guess. Config changes tend to be nasty in that their implications are often hard to oversee until they have been made, and if the effects preclude you from making another config change then you've just cut off the branch that you were sitting on. Google is best-in-class when it comes to this stuff, the thing you should…

Which seems to have been what they were trying to do; according to this update, the config change which caused the problem was intended to apply to a smaller portion of the network than it actually hit. But automated enforcement of procedures like this can also be tricky; how's a machine supposed to know that "this change was already tried on a smaller part of the network"?

Re: An update on Sunday’s service disruption

#213
post #202

Earlier quoted context omitted.

A watchdog timer is so named because it watches for some undesirable condition (usually a hang) and takes action if the condition lasts too long. This sort of auto-rollback is not that because it doesn't detect if something is bad, just rolls it back unless you tell it not to.

Actually I think a watchdog timer doesn't watch anything except it's timer. > A watchdog timer is an electronic timer that is used to detect and recover from computer malfunctions. During normal operation, the computer regularly resets the watchdog timer to prevent it from elapsing, or "timing out". It doesn't care about the state of anything except it's timer, and the only way to prevent it from activating is to res…

> Actually I think a watchdog timer doesn't watch anything except it's timer.

That's exactly how they work. A watchdog is a just a timer with a reset input and expired output, and perhaps a register for the timer period.

A practical example would a be a watchdog that ensures a control loop is in fact running, if not, reset the CPU. Let's say our control loop has a cycle never longer than 10ms. So we set the watchdog timer to 10ms. You wire the watchdog expired output to the reset pin of your CPU and put a line of code at the end of your control loop that sends a reset signal to the watchdog on each loop. If the program halts, the watchdog is allowed to expire firing the reset signal which will hopefully bring the system back without intervention.

Seen an old JK laser with a two stage hardware watchdog. The engineer who worked on it said the first stage was tied to the NMI pin of the 6809 CPU which resets the control software to a safe state. If that failed, the second stage timed out which meant that something was really wrong (cpu/memory fault) and would shut the machine down.

Re: An update on Sunday’s service disruption

#214
>the root cause of Sunday’s disruption was a configuration change that was intended for a small number of servers in a single region. The configuration was incorrectly applied to a larger number of servers across several neighboring regions

sounds like a money quote. Ability to apply config changes cross-regionally instead of incremental region by region rollout.

Re: An update on Sunday’s service disruption

#215

Earlier quoted context omitted.

I've never worked in this type of operation, can you shed some light? I would have thought there'd be some type of documentation of the dependency hierarchy for change request checklists. Or are such things not always quite as comprehensive ( or not possible to have such complex interdependencies be comprehensively documented) ?

If you build a new service that uses Spanner, you'd list Spanner as a dependency in your design doc, and maybe even decide to offer an SLO upper-bounded by Spanner's. But you wouldn't list, or even know, the transitive dependencies introduced by using Spanner. You'd more or less have to be the tech lead of the Spanner team to know all the dependencies even one level deep (including whatever 1% experiments they're run…

Got it, thank you. This type of constructive knowledge sharing is a big part of what makes HN a great community.

Re: An update on Sunday’s service disruption

#217
Who was making configuration changes on a Sunday afternoon?

Not many engineers at Google work Sundays, and most teams outright prohibit production affecting changes at weekends.

The only type of change normally allowed would be one to mitigate an outage. Do I suspect therefore that the incident was started by an on-call engineer responding to a minor (perhaps not user visible) outage made a config mistake triggering a real outage?

That seems likely because on-call engineers at weekends are at their most vulnerable - typically there is nobody else around to do thorough code reviews or to bounce ideas off. The person most familiar with a particular subsystem is probably not the person responding, so you end up with engineers trying to do things they aren't super familiar with, under time pressure, and with no support.

Re: An update on Sunday’s service disruption

#218

Earlier quoted context omitted.

How did you end up resolving your issue?

With some foresight, one schedules a task to run a few minutes in the future to revert the change.

And one tests that revert by running it with a no-op change.

And one tests that the no-op change really is no-op by running it on a test system.

Re: An update on Sunday’s service disruption

#219

This answered all the questions I had. I was really racking my brain on what one system at Google could go down to cause this much damage, but it makes perfect sense that bandwidth becoming unavailable and everything in the "default" or "bulk" traffic class being dropped would do it. The real question is whether the fix will be to not reduce bandwidth accidentally, or to upgrade customer traffic to a higher QoS class…

>Engineers building apps that depend on that know the limitations. As someone who works at a slightly smaller tech company with of similar age with similar infrastructure I assure you this is not the case. Engineers are building things that rely on other things that rely on other things. There's a point where people don't know what their dependencies are. I wouldn't be surprised if nobody actually knew there was cust…

And that is why you should switch certain classes of traffic down and eventually entirely off from time to time, to verify that everything you expect to keep working really does.

Re: An update on Sunday’s service disruption

#220

This answered all the questions I had. I was really racking my brain on what one system at Google could go down to cause this much damage, but it makes perfect sense that bandwidth becoming unavailable and everything in the "default" or "bulk" traffic class being dropped would do it. The real question is whether the fix will be to not reduce bandwidth accidentally, or to upgrade customer traffic to a higher QoS class…

Google certainly has classes of traffic that see throttling all the time, and are blocked entirely quite a lot of the time.
Post reply on HN