Earlier quoted context omitted.
+1 (I'm a Googler, opinions my own) As someone who has been on oncall for 3 year and done a decent amount of production support, this public doc better explains the cause than the internal one if you aren't well versed in the underlying infra. A config change reduced used network capacity by half, and then things started falling over. And pushing the fix took a while due to the now overloaded network.
What can prevent this from happening in the future? Why was the config change required?
An update on Sunday’s service disruption
151–160 of 220 posts
Re: An update on Sunday’s service disruption
#152Earlier quoted context omitted.
+1 (I'm a Googler, opinions my own) As someone who has been on oncall for 3 year and done a decent amount of production support, this public doc better explains the cause than the internal one if you aren't well versed in the underlying infra. A config change reduced used network capacity by half, and then things started falling over. And pushing the fix took a while due to the now overloaded network.
What can prevent this from happening in the future? Why was the config change required?
Re: An update on Sunday’s service disruption
#153Earlier quoted context omitted.
Google also posts detailed postmortems for their more significant outages. Some examples: https://status.cloud.google.com/incident/cloud-networking/18... https://status.cloud.google.com/incident/cloud-pubsub/19001 https://status.cloud.google.com/incident/cloud-networking/18... https://status.cloud.google.com/incident/cloud-networking/18... https://status.cloud.google.com/incident/compute/18012 Given that this was a m…
I hope one of the things Google learns in the post mortem is that the next day summary should clearly include that a full post mortem is coming in the next few days or however long. Half the people in this thread are overlooking that fact and going into outrage mode.
Re: An update on Sunday’s service disruption
#154Re: An update on Sunday’s service disruption
#155Re: An update on Sunday’s service disruption
#156In 50 years, historians will look back on this as the turning point of AI control of humanity, inevitably leading to the point of no return. The brain trust at Google determined that humans are too prone to error to manage their critical data centers so they trained their AI efforts upon the resiliency of their hardware and software systems (i.e. "to prevent human operators from being able to mess it up"). By the tim…
Re: An update on Sunday’s service disruption
#157This 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…
Is there any other analysis as well? For example, among the free services, maybe they rank them based on how much people will notice/how much press it would get if that service slowed down or stopped?
Re: An update on Sunday’s service disruption
#158I'm curious what the Google Cloud SLA discounts will be as a result of this.
For example for Compute Engine: https://cloud.google.com/compute/sla
Re: An update on Sunday’s service disruption
#159Re: An update on Sunday’s service disruption
#160> 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.