Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Infraestructura como código: Un arma de doble filo
Joao Correia
27 de junio de 2023 - Evangelista técnico
En un panorama tecnológico en constante evolución, la gestión de entornos complejos dista mucho de ser un paseo por el parque. Desde equipos de operaciones más grandes y costosos hasta una estandarización más estricta del hardware y el software, muchas estrategias se han puesto a prueba. La automatización y las palabras de moda del momento han tenido su momento de protagonismo.
Desde hace algún tiempo estamos adoptando el paradigma de la "infraestructura como código" (IaC). Este enfoque se adapta bien, exige menos recursos, se integra perfectamente con otras herramientas y procesos como el control de código fuente y el seguimiento de cambios, y es una forma más eficiente de gestionar las crecientes demandas del mundo digital actual.
Sin embargo, como todo, IaC tiene sus defectos. Tenemos décadas de experiencia en la gestión de la infraestructura, pero es en la parte del "código" donde surgen los problemas. Si el número de errores, parches, exploits, recompensas por errores y otras actividades asociadas sirven de indicación, está claro que tenemos margen para mejorar nuestra destreza en la codificación.
Cuando, anecdóticamente, se comparan diferentes paquetes de software no por ser eficaces o fiables, sino por ser tan defectuosos como otros paquetes o versionestratar la infraestructura como código introduce inevitablemente esos mismos errores y problemas en la propia infraestructura. Un ejemplo de ello es el reciente incidente de Azure.
La interrupción de Azure: Un caso práctico de IaC
Hace unos días, un percance en Azure afectó a clientes del sur de Brasil. Como uno de los principales proveedores de la nube, Azure se adhiere al lema "todo es código", lo que permite que la configuración de servicios, servidores, bases de datos, puntos finales, copias de seguridad y mucho más se maneje como código. Esta filosofía se extiende a la parte de gestión de Azure, no sólo a la nube orientada al cliente, donde los administradores de sistemas tratan todo como código, lo que permite la automatización de todas las operaciones.
Hace unos días, Azure estaba probando un cambio en los componentes de gestión. El objetivo era sustituir algunos componentes antiguos por otros más recientes, lo que implicaba eliminar algunos paquetes NuGet e instalar otros nuevos. Como parte del cambio de los paquetes NuGet, el código que hacía referencia a ellos también tuvo que ser ligeramente alterado - los nombres de los paquetes eran diferentes y algunas convenciones de llamada cambiaron. No fue exactamente una sustitución inmediata.
Los cambios se programaron, confirmaron, revisaron, probaron y, a continuación, se desplegaron en un entorno de pruebas conocido como "Ring 0" en Azure-land, similar al nombre del modo con mayores privilegios. Una vez que todo fue bien en el Anillo 0, los cambios se desplegaron en el Anillo 1, el entorno de producción visible para los clientes.
Sin embargo, el anillo 0, al igual que muchos entornos de laboratorio o de prueba, es una versión a escala reducida del entorno de producción, sin la misma carga, base de usuarios o interacciones intrincadas del sistema.
Curiosamente, una tarea relativamente rutinaria que los administradores de sistemas de Azure realizan en producción es crear instantáneas de las bases de datos en ejecución para depurarlas sin afectar a las cargas de trabajo reales ni a los clientes. Como no hay necesidad de crear instantáneas en un entorno de laboratorio desprovisto de bases de datos y problemas de producción reales, el Anillo 0 estaba libre de instantáneas.
Uno de los cambios en los paquetes NuGet fue un cambio en las funciones que manejan las instantáneas.
Internamente, Azure ejecuta un trabajo en segundo plano para eliminar periódicamente las instantáneas antiguas. Como no había instantáneas en el anillo 0, nunca intentó eliminar ninguna durante la fase de prueba. Sin embargo, en el entorno de producción, donde existían instantáneas, el trabajo en segundo plano se ejecutó con los cambios del paquete NuGet, y lo que antes era una llamada para eliminar una instantánea de base de datos instantánea de base de datos se transformó en una llamada para eliminar una base de datos servidor.
Como si se tratara de un lento accidente de tráfico, cuando se ejecutó la tarea se borraron todos los servidores de bases de datos que tenían una instantánea lo suficientemente antigua, mientras un servicio tras otro dejaba de responder.
Las secuelas de la interrupción de Azure
La eliminación del servidor desencadenó una cadena de acontecimientos tangencialmente relacionados:
- En Azure, un cliente no puede restaurar por sí mismo un servidor eliminado. Tiene que hacerlo el equipo de soporte de Azure.
- No todos los servidores afectados tenían el mismo tipo de copia de seguridad, lo que provocó variaciones en la velocidad de restauración. Algunas estaban almacenadas en la misma región (léase: centro de datos), mientras que otras eran geográficamente redundantes, lo que significa que estaban almacenadas en diferentes regiones de Azure. Había que transferir los datos antes de restaurarlos. Esto aumentaba el tiempo de recuperación.
- Se descubrió que algunos servidores web que dependían de los servidores de bases de datos eliminados ejecutaban una prueba al iniciarse para determinar qué bases de datos estaban disponibles y accesibles. Estas peticiones se dirigían a todos los servidores de bases de datos y tenían el efecto secundario no deseado de interferir en el proceso de recuperación de los servidores de bases de datos. Además, los servidores web, cuando la prueba fallaba, provocaban inmediatamente un reinicio. Lo cual ocurrió. Y volvió a ocurrir. Y otra vez, ya que esas bases de datos no estuvieron disponibles durante un periodo de tiempo prolongado.
- Como medida de precaución, se emplea una técnica llamada backoff cuando falla una prueba. Básicamente significa que cuando se intenta realizar una prueba y ésta falla, el periodo de tiempo hasta el siguiente reintento sigue aumentando. Este aumento puede ser lineal o exponencial, y la idea es dar tiempo suficiente para que la otra parte se recupere de cualquier situación que esté experimentando sin tener que atender esas peticiones de prueba. En este caso concreto, tuvo la consecuencia no deseada de provocar que los reinicios tardaran más de una hora, cuando normalmente tardarían segundos.
- La restauración de las copias de seguridad era lenta porque la infraestructura estaba saturada de peticiones.
- En cuanto algunos servidores volvieron a funcionar, se vieron desbordados por el tráfico de clientes.
Para permitir que todos los servidores volvieran a estar en línea, hubo que interrumpir todo el tráfico hasta que se recuperaron todos los servidores. Este pico de tráfico hizo que la interrupción (para los clientes de los inquilinos de Azure afectados) fuera más larga de lo que habría sido de otro modo.
¿El resultado? Aproximadamente 10 horas de inactividad, interrupciones de la actividad y un montón de clientes frustrados.
Y todo se originó al actualizar unos pocos paquetes de código. No un hackeo o un incendiou otro peligro.
Conclusiones y lecciones aprendidas
Es esencial disponer de un entorno de pruebas sólido, capaz de imitar la producción lo más fielmente posible. Las réplicas exactas son difíciles de conseguir, se desincronizan con facilidad y son difíciles de mantener. Pero los entornos de prueba demasiado simplistas son esencialmente inútiles, ya que carecen de los retos necesarios a los que se enfrenta el entorno de producción.
Las estrategias eficaces de copia de seguridad y restauración son cruciales. Las copias de seguridad no sólo deben estar disponibles, sino que también deben haber sido probadas en escenarios de restauración en vivo.
El error humano es un reto persistente en el desarrollo de código. Debemos reconocer la posibilidad de pasar por alto interacciones críticas y fallos potenciales en sistemas muy complejos. De hecho, los sistemas ni siquiera tienen que ser tan complejos para que los humanos carezcan de la capacidad de captar todas las complejidades e interacciones que contienen. Codificar en esa situación conduce inevitablemente a problemas.
La nube, aunque revolucionaria, no es inmune a los fallos. Los errores humanos, los fallos de software y los fallos de hardware pueden ocurrir y ocurren. Repetida e inesperadamente. Y si Murphy tiene algo que deciren el peor momento posible.
Como nota positiva, el incidente puso de manifiesto la tenacidad de los equipos de soporte y operaciones de Azure, que consiguieron restaurar los recursos eliminados sin pérdida de datos en un plazo relativamente corto. Esto subraya que, si bien la gestión de grandes infraestructuras, especialmente como código, es un reto, la verdadera medida de un servicio es la rapidez con la que responde y rectifica un problema después de un desliz.
En conclusión, siempre es aconsejable automatizar en la medida de lo posible, asegurándose de que el entorno de pruebas se asemeja lo más posible al de producción. Incidentes como estos sirven como valiosos recordatorios para tener en cuenta las posibles vulnerabilidades de nuestros entornos antes de que provoquen fallos.
También es importante automatizar primero las tareas triviales, por ejemplo despliegue automático de parches - lo que permite centrarse en operaciones más complejas que exigen un mayor nivel de atención. Esto ayuda a liberar el único recurso que la nube no puede escalar (la capacidad intelectual) para tareas más importantes.
