¿Por qué fallóMicrosoft el pasado 19 de julio?

El 19 de julio, Azure, una plataforma de servicios en la nube de Microsoft, experimentó un problema significativo. Imagínate que Azure es como una gran central de energía que alimenta muchos servicios y aplicaciones que usamos en línea. Ese día, una parte importante de esta «central» dejó de funcionar correctamente, lo que provocó que muchos servicios dependientes también dejaran de funcionar o lo hicieran de manera incorrecta.

¿Qué fue lo que falló?

La causa principal del problema fue un error en la configuración de los sistemas de almacenamiento de datos en una de sus regiones (Centro de EE.UU.). Esto afectó a las máquinas virtuales que son como los motores que mantienen en funcionamiento los servicios en la nube. Al no poder acceder a los datos necesarios, muchos servicios se detuvieron o funcionaron de manera incorrecta.

¿Por qué no debe cundir el pánico?

Microsoft abordó el problema en Azure el 19 de julio de una manera estructurada y metódica para restablecer los servicios lo más rápido posible. Aquí tienes una explicación simplificada:

1. Detección del Problema Microsoft tiene sistemas de monitoreo avanzados que detectaron rápidamente que algo estaba mal. Es como tener un tablero de control que muestra luces de advertencia cuando algo no funciona correctamente. La caída en la disponibilidad de las máquinas virtuales fue detectada a las 22:06 UTC el 18 de julio.
2. Identificación de la Causa El equipo técnico de Microsoft comenzó a investigar de inmediato para encontrar la causa del problema. Descubrieron que una actualización de configuración en los sistemas de almacenamiento había fallado, lo que provocó que muchas «máquinas virtuales» (que son Servidores en la nube) dejaran de funcionar correctamente.
3. Detención de la Actualización Problemática Una vez identificada la causa, Microsoft detuvo la actualización problemática en todo el mundo para evitar que el problema se extendiera a otras regiones. Es como si hubieran pausado un programa de actualización defectuoso antes de que causara más daños.
4. Restablecimiento de la Configuración El equipo de Microsoft trabajó para corregir la configuración en los sistemas de almacenamiento. Esto implicó cambiar las configuraciones a los estados correctos para que las máquinas virtuales pudieran volver a acceder a los datos necesarios.  Comenzó la recuperación con un proceso de geo-failover (restauración de sistemas de respaldo) a las 00:15 UTC el 19 de julio. El 80% de las bases de datos SQL se recuperaron en las primeras 2 horas. y el 98% de las bases de datos se recuperaron en las siguientes 3 horas
5. En resumen, el tiempo medio para restaurar la mayoría de los servicios a una funcionalidad aceptable fue de aproximadamente 4 a 5 horas, mientras que la recuperación completa y la resolución de todos los problemas llevaron cerca de 24 horas
6. Restauración de Servicios A medida que los sistemas de almacenamiento comenzaron a funcionar nuevamente, las máquinas virtuales y los servicios dependientes también comenzaron a recuperarse. Microsoft tuvo que realizar algunas tareas adicionales, como reiniciar sistemas y asegurarse de que todas las conexiones fueran correctas.

En resumen, el tiempo medio para restaurar la mayoría de los servicios a una funcionalidad aceptable fue de aproximadamente 4 a 5 horas, mientras que la recuperación completa y la resolución de todos los problemas llevaron cerca de 24 horas

1. Recuperación rápida: Los equipos de Azure detectaron el problema rápidamente y comenzaron a trabajar en una solución de inmediato. La mayoría de los servicios se recuperaron en pocas horas.
2. Redundancia y Resiliencia: Los servicios críticos tienen sistemas de respaldo en diferentes ubicaciones. Así, aunque una región falle, otras pueden tomar el relevo y continuar operando.
3. Aprendizaje y Mejora: Cada incidente proporciona valiosas lecciones. Azure y otros proveedores de la nube utilizan estos eventos para mejorar sus sistemas y evitar que ocurran problemas similares en el futuro.

¿Por qué el fallo del 19 de julio es inusual?

El incidente del 19 de julio fue un evento raro y aquí hay algunas razones por las cuales no debe cundir el pánico:

1. Respuesta Rápida y Eficaz:
   • Microsoft detectó el problema rápidamente y comenzó a trabajar en una solución inmediatamente. La mayoría de los servicios se recuperaron en pocas horas​ (Azure Status)​.
2. Redundancia y Resiliencia:
   • Azure está diseñado con redundancia en mente. Esto significa que si una parte del sistema falla, otras partes pueden continuar funcionando. Los servicios críticos están distribuidos en múltiples regiones para minimizar el impacto de los fallos regionales.
3. Mejoras Continuas:
   • Cada incidente proporciona valiosas lecciones. Microsoft utiliza estos eventos para mejorar sus sistemas y evitar que problemas similares ocurran en el futuro. Esto incluye mejoras en la configuración, monitoreo y respuesta a incidentes.
4. Historial de Alta Disponibilidad:
   • Azure tiene un historial de alta disponibilidad y confiabilidad. Los incidentes importantes son muy raros en comparación con la cantidad de tiempo que los servicios de Azure están operativos sin problemas.

————–

SOLICITAR INFORMACIÓN