Google Cloud ha atribuido la semana pasada interrupción generalizada a una puesta al día de código defectuoso en su sistema de control de servicio que activó un rizo de choque universal Adecuado a la equivocación de manejo de errores y la equivocación de protección contra la bandera. El registro informa: Google explicación Del incidente se abre informando a los lectores que sus API, y las de Google Cloud, se atienden a través de nuestros aviones de trámite y control de API de Google. “Esos dos aviones se distribuyen regionalmente y” son responsables de asegurar que cada solicitud de API que se realice es autorizada, tiene la política y las verificaciones apropiadas (como cuotas) para cumplir con sus puntos finales “. El binario binario es parte de este sistema de comprobación de políticas se conoce como” control de servicio “. Control de servicio”.

El 29 de mayo, Google agregó una nueva característica al control de servicio, para habilitar “verificaciones de políticas de cuotas adicionales”. “Este cambio de código y la lectura binaria pasaron por nuestra región por despliegue de región, pero la ruta del código que falló nunca se ejerció durante este despliegue adecuado a la indigencia de un cambio de política que desencadenara el código”, explica el crónica del incidente de Google. El monopolista de la búsqueda parece poseer tenido preocupaciones sobre este cambio, ya que “caldo con un interruptor rojo para apagar ese camino de servicio en particular”. Pero el cambio “no tenía el manejo de errores apropiado ni estaba protegido por el indicador de características. Sin el manejo de errores apropiado, el puntero inepto causó que el binario se bloqueara”.

Google usa banderas de características para atrapar problemas en su código. “Si esto hubiera sido protegido por la bandera, el problema habría sido atrapado en la puesta en ambiente”. Ese código desprotegido se ejecutó interiormente de Google hasta el 12 de junio, cuando la compañía cambió una política que contenía “campos en blanco no deseados”. Esto es lo que sucedió a continuación: “Control de servicio, luego ejerció regionalmente las verificaciones de cuotas sobre las políticas en cada almacén de datos regional. Esto atrajo a los campos en blanco para este cambio de política respectivo y ejerció la ruta del código que golpeó el puntero inepto que provocó que los binarios entraran en un rizo de soledad. Esto ocurrió conjuntamente cedido cada despliegue regional”.

La publicación de Google establece que su equipo de ingeniería de confiabilidad del sitio vio y comenzó a triando el incidente en dos minutos, identificó la causa raíz en 10 minutos y pudo comenzar la recuperación en 40 minutos. Pero en algunas regiones más grandes de Google Cloud, “a medida que se reiniciaron las tareas de control de servicios, creó un impresión de yeguada en la infraestructura subyacente de la que depende … sobrecarga de la infraestructura”. El control del servicio no se creó para manejar esto, por lo que tardó casi tres horas en resolver el problema en sus regiones más grandes. Los equipos que ejecutan productos de Google que cayeron adecuado a este desastre tuvieron que realizar sus propias tareas de recuperación. En el futuro, Google ha prometido un par de cambios operativos para evitar que este error vuelva a ocurrir: “Mejoraremos nuestras comunicaciones externas, tanto automatizadas como humanas, por lo que nuestros clientes obtienen la información que necesitan lo antaño posible para reaccionar a los problemas, llevar la batuta sus sistemas y ayudar a sus clientes. Aseguraremos que nuestra infraestructura de monitoreo y comunicación permanezca operativa para servir a los clientes, incluso cuando Google Cloud y nuestros productos principales de monitoreo estén en torno a debajo, garantizaremos la continuidad de los negocios”.