Brain: cómo la IA de Azure decide cuándo un servicio está realmente caído

Introducción

En un entorno como Azure, con más de 80 regiones, 500 centros de datos y 800.000 kilómetros de fibra óptica submarina, la cantidad de señales de telemetría supera por lejos lo que un equipo humano puede analizar en tiempo real. Microsoft lo sabe bien: incluso hoy, en algunos casos, son los clientes los que reportan un servicio degradado antes de que los propios sistemas de Azure lo detecten.

Para resolver este problema de comprensión de datos masivos (data comprehension), la compañía desarrolló Brain, un sistema AIOps centralizado que actúa como una capa de inteligencia artificial sobre Azure Resource Graph (ARG). Según Mark Russinovich, CTO y deputy CISO de Azure, Brain no es un proyecto nuevo: nació mucho antes del boom de la IA generativa, pero se expandió gracias a la necesidad de estandarizar métricas de salud y automatizar decisiones críticas, como declarar un outage, pausar despliegues dañinos o notificar a los clientes afectados.

Qué ocurrió

En mayo de 2024, Microsoft publicó el primer artículo de una serie titulada «Meet Brain: The AI system behind Azure reliability», donde detalló cómo este sistema opera hoy en producción. Brain no solo monitorea la salud de Azure, sino que toma acciones automáticas basadas en algoritmos de machine learning y correlación de datos. Su objetivo no es reemplazar a los equipos de ingeniería, sino acortar el tiempo de respuesta y reducir la dependencia de análisis manuales.

Orígenes: de un digital twin a un sistema de alertas inteligentes

Todo comenzó con Azure Resource Graph (ARG), lanzado como un servicio interno en 2017 para modelar la infraestructura de Azure como un digital twin. Los clientes más grandes (whale customers) exigieron acceder a consultas agregadas a nivel global, como «¿Qué máquinas virtuales Linux tengo en producción y con qué versiones de kernel?». Sobre esta base, Microsoft implementó análisis de root cause basado en gráficos de dependencias:

# Ejemplo de consulta en Azure Resource Graph para listar VMs Linux
resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend osType = tostring(properties.storageProfile.osDisk.osType)
| where osType =~ 'Linux'
| project name, location, osType, properties.hardwareProfile.vmSize

Brain evolucionó a partir de esta capa, incorporando tres tipos de señales:

1. SLIs estandarizados (Service Level Indicators): métricas normalizadas de salud emitidas por cada servicio.
2. Monitores personalizados: reglas específicas de cada equipo, como volumen de tickets de soporte o dependencias entre servicios.
3. Fuentes externas: posts en redes sociales, tickets de soporte abiertos o alertas de terceros.

El problema de los SLOs manuales

Inicialmente, Microsoft intentó que cada equipo definiera sus propios SLOs (Service Level Objectives). El resultado fue un desastre: los equipos subestimaban sus umbrales para evitar falsas alarmas, generando SLOs poco útiles. Como explicó Russinovich:

> «Todos querían ser conservadores porque no querían que les paginaran o que se notificara a los clientes cuando no había un problema real. Decidimos dejar de pedirles que definieran SLOs manualmente».

En su lugar, Brain ahora deriva umbrales automáticamente comparando el comportamiento histórico de cada servicio por región y scale unit. Por ejemplo:

• Si el 99.9% de las peticiones a una API en East US suelen responder en <200ms, pero en West Europe el percentil 99 es <150ms, cualquier degradación que supere esos percentiles locales activará una alerta.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps

Brain introduce un cambio radical en la cultura de despliegues:

• Gate automático de despliegues: Si un cambio en un servicio genera una regresión, Brain puede pausar el despliegue en tiempo real antes de que afecte a más clientes.
• Correlación de cambios con síntomas: Los algoritmos de Brain rastrean no solo el último despliegue, sino los cambios en las últimas 24-48 horas, para identificar la causa raíz. Esto es crítico en entornos donde una regresión puede tardar horas en manifestarse.

> «Una regresión puede tener latencia. En algunos casos, tarda días en aparecer, y puede haber múltiples despliegues en ese período. Por eso usamos ML para mapear síntomas con cambios» — Mark Russinovich, Azure CTO.

Para equipos de infraestructura y cloud

La automatización de Brain reduce la carga operativa en:

1. Monitoreo de SLIs: Al estandarizar métricas, los equipos ya no necesitan mantener dashboards personalizados. Cada servicio emite SLIs en un formato común, como:

   # Ejemplo de SLI en formato estándar de Azure
   apiVersion: monitoring.azure.com/v1
   kind: ServiceLevelIndicator
   metadata:
     name: api-latency-sli
   spec:
     target: "99.9%"
     windows:
       - duration: "5m"
         percentiles: ["p95", "p99"]
   

1. Notificaciones granulares: Brain envía alertas solo a los clientes afectados (por subscription y región), evitando el ruido de falsos positivos.

Para equipos de seguridad

Brain incorpora fuentes no tradicionales para detectar fallos:

• Tickets de soporte: Si un cliente abre un ticket reportando un problema, el sistema lo correlaciona con métricas internas.
• Redes sociales: Publicaciones en Twitter/X o LinkedIn que mencionen «Azure down» se integran como señales de alerta temprana.

Esto es especialmente útil para detectar ataques de denegación de servicio distribuidos (DDoS) o fallos en cascada que comienzan como problemas menores pero escalan rápidamente.

Detalles técnicos

Arquitectura de Brain

Brain opera como una capa de inteligencia sobre ARG, con los siguientes componentes clave:

1. SLIs estandarizados:

– Tasas de error por endpoint.

– Disponibilidad por scale unit (ej: 99.95% en North Europe).

– Fuente: Microsoft Learn – SLI/SLO en Azure

1. Monitores personalizados:

– Dependencias entre servicios (ej: si Azure SQL falla, Azure Functions que dependen de él se marcan como degradados).

– Fuente: Azure Monitor – Workbooks

1. Fuentes externas:

– Posts en Stack Overflow con etiquetas como azure + palabras clave como timeout.

Métricas de desempeño (según Microsoft)

• Precisión de detección: Mejoró un 30% desde su implementación inicial (2021).
• Notificaciones automáticas: El 85% de los outages integrados con Brain se comunicaron automáticamente a clientes en 2023 (vs. 30% manual).
• Tiempo de notificación: Se redujo de horas a minutos en el 70% de los casos.

Vulnerabilidades y riesgos

Aunque Brain mejora la resiliencia, introduce nuevos desafíos:

1. Falsos positivos: Si un SLI se configura demasiado sensible, puede activar alertas innecesarias. Para mitigarlo, Brain usa:

– Feedback loop: Los equipos pueden marcar alertas como «falsas» para ajustar modelos.

1. Dependencia de ARG: Si ARG falla, Brain pierde visibilidad. Microsoft usa replicación multi-región para ARG, pero el riesgo persiste.

> «Brain depende de que los servicios emitan SLIs correctamente. Si un equipo no actualiza su biblioteca de SLI, su servicio puede quedar ‘invisible’ para el sistema» — Russinovich.

Qué deberían hacer los administradores y equipos técnicos

1. Emitir SLIs estandarizados en sus servicios

Si tu equipo opera servicios en Azure, debes emitir SLIs en el formato estándar para que Brain pueda consumirlos. Ejemplo para una API en .NET:

// Biblioteca oficial de Azure SLI para .NET
using Azure.Monitor.Metrics;
using Azure.Monitor.Metrics.Generated;

var meter = new Meter("Contoso.Api");
var latencyHistogram = meter.CreateHistogram<double>("api.latency.ms", unit: MeasurementUnit.Duration.Milliseconds);

// En cada petición HTTP
var startTime = DateTime.UtcNow;
try
{
    await _next(context);
    var duration = (DateTime.UtcNow - startTime).TotalMilliseconds;
    latencyHistogram.Record(duration, new KeyValuePair<string, object>("endpoint", context.Request.Path));
}
catch (Exception ex)
{
    // Registrar error
}

1. Instalar el paquete NuGet Azure.Monitor.Metrics (versión 1.0.0+).
2. Configurar percentiles p95 y p99 para latencia.
3. Usar el tag service.name para identificar el servicio en ARG.

2. Configurar alertas basadas en SLIs

En Azure Monitor, crea alertas que usen los SLIs de Brain:

# Plantilla ARM para alerta basada en SLI
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Insights/metricAlerts",
      "apiVersion": "2018-03-01",
      "name": "HighLatencyAlert",
      "location": "global",
      "properties": {
        "description": "Alerta para SLI de latencia >200ms (p95)",
        "severity": 2,
        "enabled": true,
        "scopes": ["/subscriptions/{subscription-id}"],
        "evaluationFrequency": "PT1M",
        "windowSize": "PT5M",
        "criteria": {
          "odata.type": "Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria",
          "allOf": [
            {
              "name": "High Latency",
              "metricName": "api.latency.ms",
              "dimensions": [
                {
                  "name": "endpoint",
                  "operator": "Include",
                  "values": ["users/*"]
                }
              ],
              "operator": "GreaterThan",
              "threshold": 200,
              "timeAggregation": "Average"
            }
          ]
        }
      }
    }
  ]
}

3. Integrar Brain con tus pipelines de CI/CD

Brain puede pausar despliegues si detecta una regresión. Para ello, usa Azure Pipelines con la tarea AzureFunction para invocar la API de Brain:

# Ejemplo de pipeline en YAML para pausar despliegues problemáticos
trigger:
  - main

steps:
  - task: AzureCLI@2
    displayName: "Verificar salud con Brain"
    inputs:
      azureSubscription: 'Contoso-DevOps'
      scriptType: 'ps'
      scriptLocation: 'inlineScript'
      inlineScript: |
        $healthState = az rest --method get --uri "https://management.azure.com/providers/Microsoft.ResourceHealth/availabilityStatuses/current?api-version=2022-10-01" | ConvertFrom-Json
        if ($healthState.properties.impactedResources -gt 0) {
          Write-Host "##vso[task.logissue type=error]Servicio degradado. Pausando despliegue."
          exit 1
        }

4. Monitorear los gates de Brain

Brain expone endpoints para verificar su estado. Usa el CLI de Azure para consultarlos:

# Verificar si Brain está activo en tu suscripción
az rest --method get \
  --uri "https://management.azure.com/providers/Microsoft.ResourceHealth/availabilityStatuses/current?api-version=2023-08-01-preview" \
  --query "properties.impactedResources"

Si el valor es >0, significa que hay recursos degradados en tu suscripción.

5. Preparar un plan de respuesta a outages

Brain notifica automáticamente a los clientes afectados, pero tu equipo debe:

1. Definir un runbook para cuando Brain declare un outage:

– ¿Cómo escalas a Microsoft si el problema es global?

1. Probar integraciones: Usa el entorno de pruebas de Brain para simular fallos y validar tus alertas.

Conclusión

Brain representa un salto cualitativo en la confiabilidad de Azure, pero su éxito depende de que los equipos adopten prácticas clave:

• Emitir SLIs estandarizados para que el sistema pueda correlacionar datos.
• Automatizar respuestas a regresiones en pipelines de CI/CD.
• Integrar fuentes de datos diversas (soporte, redes sociales) para detectar fallos tempranos.

Para los equipos de DevOps, esto significa menos tiempo en war rooms y más tiempo en innovación. Para los equipos de seguridad, una capa adicional de detección de anomalías. Y para los clientes, menor tiempo de inactividad.

Como dijo Russinovich:

> «El objetivo no es reemplazar a los ingenieros, sino darles herramientas para que resuelvan problemas 10 veces más rápido».

FIN