Un error tipográfico bloquea Azure DevOps durante varias horas

Los servicios en la nube están lejos de estar libres de cortes e interrupciones del servicio. Los clientes de Microsoft que utilizan instancias de Azure DevOps en la región Sur de Brasil (SBR) lo saben, ya que experimentaron una falta de disponibilidad de este entorno durante casi las 10:30 a. m. del miércoles 24 de mayo. El viernes pasado, se brindaron explicaciones sobre el origen y el alcance de esta falla. mostrando cómo el más mínimo grano de arena puede atascar una máquina bien engrasada.

“Somos conscientes del impacto que pueden tener las interrupciones de Azure DevOps y nos disculpamos sinceramente con todos los clientes afectados”, escribió Eric Mattingly, jefe de ingeniería de software, en una publicación de blog de análisis post-mortem. en Microsoft. “Los ingenieros de Azure DevOps a veces necesitan tomar una instantánea de una base de datos de producción para investigar las quejas de los clientes o evaluar posibles mejoras de rendimiento. Para garantizar que estas bases de datos de instantáneas se limpien, una tarea en segundo plano se ejecuta todos los días y las elimina después de que superan un tiempo determinado.

Un fallo detectado en 20 minutos

Como parte de un sprint, se realizó una actualización de código para reemplazar los paquetes obsoletos (Microsoft.Azure.Managment.*) por otros más nuevos (NuGet Azure.ResourceManager.*) que requerían cambios en las llamadas a la API. "Esta solicitud ocultó un error tipográfico en la tarea Eliminar instantáneas, que reemplazó una llamada de eliminación de Azure SQL Database con una llamada similar en Azure SQL Server que aloja la base de datos", advirtió Microsoft. "Las condiciones bajo las cuales se ejecuta este código son raras y nuestras pruebas no las cubrieron bien". Con la consecuencia de desembocar en un bonito lío. “Cuando la tarea eliminó Azure SQL Server, también eliminó las diecisiete bases de datos de producción de la unidad de escala. A partir de ese momento, la unidad de báscula ya no pudo manejar el tráfico de clientes”.

Sin embargo, más miedo que daño para Microsoft, que indica que no se perdieron datos en este incidente. Pero habrá puesto en aprietos a sus equipos, habiendo tardado casi 10.30 horas en solucionarlo. “Detectamos la interrupción dentro de los 20 minutos posteriores al comienzo de las eliminaciones de la base de datos y nuestros ingenieros de guardia respondieron de inmediato. El problema se entendió rápidamente y nos pusimos manos a la obra para restaurar el servidor SQL y todas las bases de datos, además de deshabilitar la tarea de eliminar instantáneas para evitar que el error afectara a otros clientes”, continúa Eric Mattingly. Se han aducido varias razones para explica esto retraso inusual incluida la imposibilidad de los clientes de restaurarse a sí mismos, múltiples configuraciones de copia de seguridad que generan problemas de reconciliación, sin mencionar los múltiples errores de procesamiento en los servidores web de Microsoft.

Medidas para evitar un incidente de esta magnitud

Para evitar revivir tal percance, la compañía de Redmond indica que ha tomado varias medidas, incluida una prueba para la tarea de eliminación de instantáneas, la adición de medidas de seguridad para Azure Resource Manager para evitar la eliminación accidental, la creación de instantáneas de bases de datos de datos creados en instancias de Azure SQL Server. Aparte de las bases de datos de producción de Microsoft, se corrigió la lógica de la tarea de calentamiento del servidor web para permitir un inicio exitoso incluso si las bases de datos están fuera de línea. "Estamos creando un nuevo cmdlet para restaurar bases de datos eliminadas para garantizar que las restauraciones usen la misma configuración que antes de la eliminación, incluida la redundancia de respaldo", dijo Mattingly.