Compartir a través de

Análisis de la causa principal en el agente de SRE de Azure

Sugerencia

  • Use la investigación controlada por hipótesis, no la búsqueda aleatoria de registros.
  • Proporcione una cadena de evidencia completa que muestre por qué esta es la causa.
  • Recuerde incidentes anteriores similares y sus correcciones.

El problema: la búsqueda de registros no es investigación

La mayoría de las depuraciones comienzan por "mostrarme los errores". Puede consultar registros, desplazarse por los resultados, copiar una marca de tiempo, cambiar herramientas y ejecutar otra consulta. No estás investigando. Tú estás correlacionando los datos manualmente y manteniendo el razonamiento en tu mente.

El problema real no es encontrar registros. Es saber qué preguntas hacer, qué herramientas verificar y cómo conectar los puntos entre registros, métricas, implementaciones e incidentes anteriores. Ese modelo mental vive en la cabeza de sus ingenieros superiores, y no pueden estar en todas las llamadas. Los nuevos miembros del equipo pasan horas en problemas que los veteranos resuelven en minutos, ya que el razonamiento no está documentado en ningún lugar.

Cómo resuelve este problema el agente de SRE de Azure

Diagrama que muestra el flujo de análisis de la causa principal de la recopilación de evidencias a través de la validación de hipótesis hasta la conclusión.

El agente investiga como un experto en SRE. No solo busca archivos de registro. Forma hipótesis sobre lo que salió mal y valida sistemáticamente cada uno con evidencia.

  1. Recopila contexto: consulta Application Insights, Azure Monitor, historial de implementación, registros de actividad y propiedades de recursos.
  2. Formula hipótesis: Genera teorías basadas en el patrón de evidencia.
  3. Valida cada uno: prueba las hipótesis sistemáticamente, descartando posibles falsos.
  4. Explica la conclusión: muestra el rastro de razonamiento completo con pruebas de apoyo y citas.

Lo que hace que esto sea diferente

A diferencia de la búsqueda de registros, el agente razona sobre el problema. "Mostrarme errores" proporciona datos para interpretar. El agente interpreta los datos para usted mediante la formación de teorías, sus pruebas y la explicación de conclusiones.

A diferencia de los paneles estáticos, el agente se adapta al incidente específico. No solo muestra métricas. Decide qué métricas importan, las correlaciona con otras evidencias y le indica por qué.

A diferencia de los scripts, el agente gestiona situaciones nuevas. Un script ejecuta los mismos pasos cada vez. Su agente tiene motivos sobre lo que es diferente esta vez y ajusta su investigación en consecuencia.

Capacidad Lo que contribuye
Memoria "Vimos este problema exacto hace 3 semanas. La corrección fue X".
Knowledge Base Los manuales operativos y los documentos de arquitectura guían la elaboración de hipótesis.
Código fuente Correlación de errores con el código fuente y búsqueda de cambios relacionados
Subagentes Delegar a especialistas específicos del servicio (Application Insights, AKS, Container Apps, etc.)

Antes y después

Categoría antes de después de
Enfoque de investigación Busca en los registros, espero que encuentres algo. Un agente conforma y prueba hipótesis
Herramientas abiertas Más de 4 portales, correlación manual 0 (el agente consulta todos los orígenes)
Reasoning "Creo que es la base de datos..." DTU de la base de datos al 98%, validado
Pista de evidencia En tu mente Cadena completa con explicación
Próxima vez Iniciar desde cero Memoria recupera incidentes similares

Ejemplo: investigación de tiempo de espera de la base de datos

Síntoma: "500 errores en el punto de conexión /api/orders"

HYPOTHESIS 1: Recent deployment broke something
├─ Checked: Last deployment was 3 days ago
├─ Evidence: Error rate stable until 30 minutes ago
└─ Result: INVALIDATED

HYPOTHESIS 2: Database overloaded
├─ Checked: Azure SQL metrics (CPU, DTU, connections)
├─ Evidence: DTU at 98%, query duration 4x normal
├─ Traced: SELECT * FROM orders WHERE... taking 8.2s
└─ Result: VALIDATED

ROOT CAUSE: Orders table missing index on customer_id column.
Query plan shows full table scan on 2.1M rows.

RECOMMENDED ACTION: Add index on orders.customer_id
Similar fix applied in INC-2341 (3 weeks ago)

Empieza ahora

El análisis de la causa principal funciona automáticamente con las herramientas integradas de Azure. Para habilitar un análisis más profundo, tenga en cuenta las siguientes mejoras.

Mejora Lo que permite Configuración
Control de código fuente Correlación de errores a código, búsqueda de código semántico Conexión del código fuente
Base de conocimiento Contexto para la generación de hipótesis Carga de conocimientos
Telemetría personalizada Métricas empresariales en Kusto Conector Kusto

Paso siguiente

Ejecución de una investigación profunda

Contenido relacionado

  • Last updated on