Live data from Hacker News

An update on Sunday’s service disruption

cloud.google.com

41–50 of 220 posts

Re: An update on Sunday’s service disruption

#41
post #35
post #29

This is a surprisingly vague postmortem. No timeline, no specific identification of affected regions. And no explanation of why a configuration change that was (apparently) made with a single command required so much effort to undo, or why repair efforts were hampered when (again, apparently) the network was successfully prioritizing high-priority traffic. Even for a public postmortem, this seems pretty weak.

> With all services restored to normal operation, Google’s engineering teams are now conducting a thorough post-mortem ... This is not the post-mortem, that is still to come.

The article leaves it to the reader to decide whether or not we will be updated with the results of that post-mortem.

Re: An update on Sunday’s service disruption

#42
post #5

> In essence, the root cause of Sunday’s disruption was a configuration change I feel like I hear about config changes breaking these cloud hosts so often it might as well be a meme. Is there a reason why it's usually configurations to blame vs code, hardware, etc?

In a well designed system I guess this is the only thing that can go wrong.

Re: An update on Sunday’s service disruption

#43
This seems a quick write up from a manager to the managers that simply says how big they are and that they are sorry. I doubt the public will ever see a technical postmortem.

Still there are great lessons in this incident for them as much as for all SREs around the world who struggled during the incident. I for one wouldn't want to rely on a global load balancer which I know now that can not survive a regional outage.

Re: An update on Sunday’s service disruption

#44
> [A] configuration change [...] 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, and it caused those regions to stop using more than half of their available network capacity. The network traffic to/from those regions then tried to fit into the remaining network capacity, but it did not. The network became congested, and our networking systems correctly triaged the traffic overload and dropped larger, less latency-sensitive traffic in order to preserve smaller latency-sensitive traffic flows...

> Google’s engineering teams detected the issue within seconds, but diagnosis and correction took far longer than our target of a few minutes. Once alerted, engineering teams quickly identified the cause of the network congestion, but the same network congestion which was creating service degradation also slowed the engineering teams’ ability to restore the correct configurations, prolonging the outage.

Someone forgot to classify management traffic as high-priority? Oops.

The description is vague about what devices ("servers") were misconfigured. Did someone tell all google service pods in the affected regions to restrict bandwidth by over 50%? Mentioning "server" and then talking about network congestion is confusing. How would restricted bandwidth utilization on servers cause network congestion, unless load balancers saturated the network by re-sending requests to servers because none of them were responding?

Re: An update on Sunday’s service disruption

#46
post #27
post #5

> In essence, the root cause of Sunday’s disruption was a configuration change I feel like I hear about config changes breaking these cloud hosts so often it might as well be a meme. Is there a reason why it's usually configurations to blame vs code, hardware, etc?

Well you can't just change code, it has to get reviewed, it has to go to QA, it has to go to UAT, it has to get signed off in triplicate by all the major stake holders. Configuration changes are easy though, they don't have to go through all these error prevention steps, we can just have our less technical support staff make configuration changes live in production. In fact we'll build them a DSL so we never have to…

I guarantee that Google does not allow non-technical support staff to make configuration changes to the core routing infrastructure of their datacenters. Other places might, but they run a much tighter ship than that.

Re: An update on Sunday’s service disruption

#47
post #24
post #2

> For most Google users there was little or no visible change to their services—search queries might have been a fraction of a second slower than usual for a few minutes but soon returned to normal, their Gmail continued to operate without a hiccup, and so on. Google probably forgot that some of their own brands are also hosted on their cloud. Like Nest. Basically Nest was down entirely.

Most importantly, commerical gsuite was down. Its paid service(with bad, but still a SLA), and some companies worked on sunday. Pretty bad when both corp email and hangouts dont work - no way to communicate remediation steps.

Good takeaway: don’t use the same communications provider for all of your collaboration needs.

However figuring out, for example, whether Slack has a critical dependency on your provider may not be trivial.

Re: An update on Sunday’s service disruption

#48
post #10

Earlier quoted context omitted.

Code is reviewed, but I'm not aware of any companies where terminal commands are reviewed before each execution (though maybe they should be - it seems like every major cloud outage is config related). It sounds like the change was reviewed and approved but incorrectly pushed.

We do at AWS. Not all commands though, but most commands that we audit and find are dangerous. See a similar outage in S3 from 2 years ago - https://aws.amazon.com/message/41926/

How do this code-review of cmds work? Does the command get saved to a file, and then that file is reviewed like regular source-code, and then when it is approved the cmd is copy-pasted back to the terminal and run?

That above seems pretty clunky, so it's very likely not what happens.

Re: An update on Sunday’s service disruption

#49
post #2

> For most Google users there was little or no visible change to their services—search queries might have been a fraction of a second slower than usual for a few minutes but soon returned to normal, their Gmail continued to operate without a hiccup, and so on. Google probably forgot that some of their own brands are also hosted on their cloud. Like Nest. Basically Nest was down entirely.

GitHub hooks for google cloud builder were also down, meaning if you chose google for deployment automation you were SOL. It wasn’t shown as down under any of the status pages, but it was definitely down for us.

I get that outages happen. But having a dishonest status page just plain sucks.

Re: An update on Sunday’s service disruption

#50
post #37
post #35

Earlier quoted context omitted.

> With all services restored to normal operation, Google’s engineering teams are now conducting a thorough post-mortem ... This is not the post-mortem, that is still to come.

The postmortem is currently only visible to Googlers.

What happened?
Post reply on HN