Una interrupción en Microsoft Azure DevOps en Brasil ha sido causada por un error tipográfico en el código de actualización.
El miércoles 24 de mayo, Microsoft Azure DevOps se desconectó de las 12:10 a las 22:31 UTC después de que Azure SQL Server se eliminara accidentalmente.
En un informe de actualización de estado, el gerente principal de ingeniería de software de Microsoft, Eric Mattingly, dijo: “Durante Sprint 222, actualizamos nuestra base de código para reemplazar el obsoleto Microsoft.Azure.Management.
"Esto resultó en una gran solicitud de extracción de cambios mecánicos que intercambiaban llamadas API. Oculto dentro de esta solicitud de extracción había un error tipográfico en el trabajo de eliminación de instantáneas que cambió una llamada para eliminar Azure SQL Database a una que elimina Azure SQL Server que aloja la base de datos.”
Los ingenieros de DevOps toman instantáneas de las bases de datos con regularidad para explorar problemas o probar mejoras y confían en un sistema en segundo plano que se ejecuta a diario y elimina las instantáneas antiguas.
Sprint 222 inicialmente se ejecutó internamente sin problemas pero, cuando se implementó en el entorno del cliente, tuvo acceso a una base de datos de instantáneas lo suficientemente antigua como para activar el error de eliminación.
Al eliminar el servidor en lugar de la base de datos prevista, el código eliminó las diecisiete bases de datos de producción para la unidad de báscula, por lo que no pudo procesar las solicitudes de los clientes. Según la compañía, no hubo pérdida de datos durante la interrupción.
A pesar de que Azure se dio cuenta del problema en 20 minutos, solucionarlo llevó más de 10 horas. Según Mattingly, esto se debió en parte a que un ingeniero de Azure se involucró y trabajó en el problema y algunas bases de datos se crearon antes de que la copia de seguridad con redundancia de zona geográfica estuviera disponible, lo que significa que algunas bases de datos tuvieron que copiarse en una región emparejada, lo que agregó varias horas.
La causa final de la demora, según Mattingly, fue el resultado de una serie de problemas con los servidores de Azure en los que los procesos w3wp seguían reciclándose y cada vez realizaban una tarea de calentamiento que tardaba alrededor de 90 minutos en completarse.
“Dado que este proceso se escalonó entre todos los servidores web, para cuando terminó, solo uno o dos servidores estarían nuevamente en el balanceador de carga y recibiendo tráfico de clientes. Entonces se sobrecargarían y el ciclo comenzaría de nuevo. Hacia el final de la ventana de interrupción, bloqueamos todo el tráfico a la unidad de escala con nuestra función de utilización de recursos para permitir que todos los servidores web se calentaran e ingresaran correctamente al balanceador de carga. Esto resultó en que los usuarios recibieran límites de tarifas y errores de uso. Una vez que todas las bases de datos estuvieron en buen estado, desbloqueamos gradualmente a los usuarios para aumentar el tráfico de clientes a niveles normales”, dijo Mattingly.
Microsoft ha implementado varios ajustes para evitar que esto vuelva a ocurrir en el futuro.
En enero de este año, Microsoft sufrió una interrupción generalizada que afectó a 365, Outlook, GitHub, Teams y más. La interrupción duró cinco horas y finalmente se explicó por un cambio de IP del enrutador de red de área amplia (WAN).