Microsoft Azure DevOps, un conjunto de servicios de ciclo de vida de aplicaciones, dejó de funcionar en la región sur de Brasil durante unas diez horas el miércoles debido a un error de código fundamental.
El viernes, Eric Mattingly, director principal de ingeniería de software, se disculpó por la interrupción y reveló el motivo de la misma: error tipográfico simple Eso eliminó diecisiete bases de datos de producción.
Mattingly explicó que los ingenieros de Azure DevOps a veces toman instantáneas de las bases de datos de producción para ver los problemas informados o probar las mejoras de rendimiento. Se basan en un sistema en segundo plano que se ejecuta a diario y elimina las instantáneas antiguas después de un período de tiempo determinado.
durante los últimos tiempos el enemigo – Proyecto de equipo ágil: los ingenieros de Azure DevOps han realizado una actualización de código, reemplazando Microsoft.Azure.Management. * Paquetes compatibles Azure.ResourceManager. *NuGet.
El resultado fue una gran solicitud de extracción de cambios que reemplazó las llamadas a la API en los paquetes antiguos con las de los paquetes más nuevos. Se escribió mal una solicitud de extracción: un cambio de código que debe revisarse y fusionarse en el proyecto correspondiente. Y la tarea de eliminación de instantáneas en segundo plano llevó a eliminar todo el servidor.
«Oculto dentro de esta solicitud de extracción había un error tipográfico en la tarea de eliminación de instantáneas que reemplazó una llamada para eliminar la base de datos de Azure SQL con una que elimina el Azure SQL Server que aloja la base de datos», dijo Mattingly.
Azure DevOps tiene pruebas para detectar tales problemas, pero según Mattingly, el código defectuoso solo funciona bajo ciertas condiciones y, por lo tanto, no está bien cubierto en las pruebas existentes. Estas condiciones presumiblemente requieren una instantánea de la base de datos que sea lo suficientemente antigua como para ser detectada por el script de eliminación.
Mattingly dijo que el Sprint 222 se implementó internamente (Anillo 0) sin incidentes porque no había bases de datos de instantáneas. Después de varios días, los cambios de software se propagaron en el entorno del cliente (anillo 1) de la unidad de escala del Sur de Brasil (un grupo de servidores para un rol específico). Este entorno tenía una base de datos de instantáneas que era lo suficientemente antigua como para desencadenar el error, lo que provocó que el trabajo en segundo plano eliminara «todo Azure SQL Server y las 17 bases de datos de producción» para la unidad de medida.
Se recuperaron todos los datos, pero tomó más de diez horas. Mattingly dijo: Hay varias razones para eso.
Una es que, dado que los clientes no pueden revivir Azure SQL Server por sí mismos, los ingenieros de Azure On-Demand tuvieron que encargarse de eso, un proceso que tomó alrededor de una hora para muchos usuarios.
Otra razón es que las bases de datos tienen diferentes configuraciones de copia de seguridad: algunas están configuradas para copias de seguridad regionales y otras están configuradas para la copia de seguridad más reciente en la región geográfica. Resolver este desajuste agregó muchas horas al proceso de recuperación.
«Finalmente, incluso después de que las bases de datos comenzaron a volver a estar en línea», dijo Mattingly, «toda la unidad de dominio permaneció inaccesible incluso para los clientes cuyos datos estaban en esas bases de datos debido a un complejo conjunto de problemas con nuestros servidores web».
Estos problemas surgieron de una tarea de preparación del servidor que iteraba a través de la lista de bases de datos disponibles con una llamada de prueba. Las bases de datos que estaban en recuperación arrojaron un error que activó la prueba de calentamiento para «realizar un reintento de reversión exponencial que resultó en que el calentamiento tomara un promedio de noventa minutos, en comparación con menos de un segundo en lo normal».
Para empeorar las cosas, este proceso de recuperación se escalonó y tan pronto como uno o dos de los servidores comenzaban a recibir tráfico de clientes nuevamente, se sobrecargaban y caían. Al final, restaurar el servicio requería bloquear todo el tráfico a la SBU hasta que todo estuviera lo suficientemente listo para volver a unirse al balanceador de carga y manejar el tráfico.
Se han realizado varias correcciones y reconfiguraciones para evitar que el problema se repita.
«Una vez más, nos disculpamos con todos los clientes afectados por este apagón», dijo Mattingly. ®
«Fanático del café. Amable aficionado a los zombis. Devoto practicante de la cultura pop. Malvado defensor de los viajes. Organizador típico».