Mi infra en Azure no funciona, algo cambió pero no se que fue. Change Analysis al rescate



Creo que no soy el único que a lo largo de su carrera profesional, en este mundo de IT le hayan realizado más de una vez la siguiente pregunta:

¿Oye no se habrá tocado algo en producción?

Entonces a ese pregunta, uno responde defendiéndose con otra pregunta de la que ya se sabe la respuesta de antemano jajaja:

Yo no he tocado nada. ¿Es qué pasa algo?

Y te responden:

Es que no funciona, esto y tampoco esto…

Después de esta breve conversación, ya empezamos a ver como solucionar el problema, haciendo cosas como:

  • Lo primero, intentar mitigar el problema.
  • Revisar las configuraciones.
  • Preguntar a otra gente si ellos han cambiado algo, este es un clásico.
  • Revisar si se ha desplegado código nuevo.

Con suerte puede ser que encuentres el problema en 1 minuto, pero lo mismo tardas 1 o 2 horas que 6 horas. Después te “acuerdas” o “descubres”, que en realidad si cambiaste algo, y que eso provocó el problema (a mí me ha pasado más de una y de dos veces lo reconozco jajaja).

Pues para resolver de manera rápida que cambios hemos realizado en nuestra infraestructura de Azure, que hayan podido provocar un outage, errores, configuraciones erróneas de servicios tenemos a nuestra disposición Change Analysis.

Change Analysis es un servicio de Azure, totalmente gratuito dentro de la plataforma Azure Monitor. Tal y como dice la documentación oficial:

Change Analysis detecta varios tipos de cambios, desde la capa de infraestructura hasta la implementación de aplicaciones. Estos cambios son :

  • Comprueba los cambios de recursos a nivel de la suscripción.
  • Proporciona datos para varias herramientas de diagnóstico para ayudar a los usuarios a comprender qué cambios causaron problemas.

Para entrar más en detalle sobre Change Analysis, podéis visitar la página oficial del servicio:

https://learn.microsoft.com/en-us/azure/azure-monitor/change/change-analysis

Una vez explicado brevemente que es Change Analysis, veamos un ejemplo práctico para ver las bondades del servicio:

Supongamos que tenemos la siguiente infraestructura en Azure (muy simple pero útil para el ejemplo):

Tenemos 2 App Services, uno es una aplicación web y la otra una API.

La API tiene configurada VNet Integration (https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration) para poder acceder a la red donde tenemos una máquina de SQL Server donde esta la BD que la API usa.

La API accede a través del puerto 1433 de la VM a la base de datos. Todo esta funcionando correctamente, cuando un día de repente la API falla. Vamos a ver en Change Analysis si algo ha cambiado en nuestra infraestructura.

Los pasos que hacemos son:

  • Accedemos al portal de Azure a través de https://portal.azure.com

  • Buscamos Monitor, en la búsqueda. Pulsamos en Monitor:


    image01



  • Una vez dentro, pulsamos en View en el apartado de Change Analysis


    image02


  • Y una vez entramos en Change Analysis, nos aparece la verdad sobre nuestros ojos:


    image04

Se nos dice que se ha cambiado una regla del network security group de Allow a Deny. Y además se nos dice que se ha modificado el rango de IPs de la regla.

  • Podemos entrar más en detalle. pulsando sobre la propiedad que cambió:


  • Podemos ver hasta quien hizo el cambio:


    image06

Después de ver esta información, se determinó que el problema de la API fue sin duda los cambios realizados en el network security group. Estos cambios provocaron que no se pudiera acceder a la base de datos desde la API.

Como conclusión, deciros que de verdad le echéis un ojo a este servicio porque os va ayudar mucho. También recordaros la importancia de desplegar vuestra infraestructura siempre como infraestructura cómo código (IAC), ya sea Bicep, plantillas ARM, Pulumi, Terraform. Lo importante, sin importar la tecnología a usar es que uséis siempre IAC.

Saludos y !Hasta la próxima¡