Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El agente diagnostica problemas y los corrige. Reinicia los servicios, escala los recursos, protege la configuración de seguridad y recopila diagnósticos, todo ello con el nivel de control que elija.
[!VÍDEO <VIDEO_URL>/Azure_SRE_Agent__Verified_Fix.mp4]
Sugerencia
- Pida al agente que corrija un problema. Propone una solución, la aprueba y ejecuta la corrección.
- Registro de auditoría completo: quién lo desencadenó, qué cambió y si funcionó.
- Elija el nivel de confianza: modo de revisión (aprobar cada acción) o modo autónomo (el agente lo controla).
El problema: el diagnóstico sin acción pierde tiempo
Ha identificado el problema. ¿Ahora qué? Vaya al portal de Azure, busque la pantalla correcta, confirme el recurso, haga clic en los cuadros de diálogo de confirmación, espere a que se complete la operación y luego verifique que haya funcionado. La investigación tardó cinco minutos. La solución toma otros diez minutos.
Esta fricción existe en los flujos de trabajo operativos:
- Operaciones diarias: escale los recursos para la carga esperada, reinicie los servicios durante las ventanas de mantenimiento.
- Comprobaciones de cumplimiento: proteja la configuración de seguridad en docenas de cuentas de almacenamiento.
- Respuesta a la llamada: ejecute correcciones conocidas rápidamente para que los ingenieros puedan volver a dormir.
- Optimización proactiva: ajuste las SKU en función de los patrones de uso antes de que se produzcan problemas.
Cómo su agente completa el ciclo
Cuando el agente identifica un problema, no deja de decirle lo que está mal. Propone una acción de corrección específica y, en función del modo de ejecución, espera la aprobación o ejecuta la acción inmediatamente.
El agente sigue un patrón coherente: diagnosticar → identificar la acción → comprobar los permisos → ejecutar (o proponer) → comprobar que ha funcionado la corrección. Cada acción se registra con quién lo desencadenó, qué cambió, por qué y si se realizó correctamente.
Después de investigar, el agente puede realizar acciones directas, crear elementos de seguimiento o notificar a su equipo, cada uno con contexto completo.
Lo que hace que esto sea diferente de los scripts
Los scripts son rígidos. Ejecutan la misma acción independientemente del contexto. Su agente primero razona sobre la situación. Considera lo que encontró durante la investigación, lo que recuerda de incidentes anteriores y cuáles recomiendan sus aptitudes y la base de conocimiento . El mismo síntoma puede provocar un reinicio en un caso y una escala vertical en otro, ya que el agente se adapta en función de la evidencia.
Los modos de ejecución le dan confianza graduada. Comience en el modo de revisión donde el agente propone y apruebe. Vaya a Autónomo cuando esté seguro del patrón. Use ReadOnly para los agentes de solo supervisión que nunca realicen acciones.
Qué puede hacer el agente
El agente puede ejecutar cualquier acción de Azure mediante comandos de la CLI de Azure. Si puede ejecutarlo en az, el agente también puede ejecutarlo. Esta funcionalidad incluye administrar cualquier tipo de recurso, modificar configuraciones, crear recursos y ejecutar cualquier operación de Azure.
| Tipo de comando | Lo que permite |
|---|---|
| Leer comandos | Consulte cualquier recurso de Azure: az webapp list, az containerapp show, az vm list, . az network vnet show Se ejecuta inmediatamente, sin necesidad de aprobación. |
| Comandos de escritura | Modifique cualquier recurso de Azure: az webapp restart, az containerapp update, az vm resize, . az role assignment create Requiere aprobación en modo de revisión. |
Las acciones del agente solo están restringidas por los permisos asignados a su identidad administrada. Si concede colaborador en un grupo de recursos, el agente puede administrar todo lo que hay en ese grupo. Si concede un rol personalizado con acciones específicas, el agente se limita a esas acciones.
Barreras de protección de seguridad
El agente aplica restricciones de seguridad en el nivel de comando.
-
Eliminar operaciones bloqueadas : el agente nunca ejecuta
deletecomandos yremove. Devuelve un error que dirige a los usuarios al portal de Azure para eliminaciones. -
Comandos de Key Vault bloqueados : el agente bloquea todos los
az keyvaultcomandos para evitar la exposición de credenciales. - Bloqueos de administración respetados : antes de modificar cualquier recurso, el agente comprueba si hay bloqueos de administración de Azure. No se pueden modificar los recursos con bloqueos readOnly.
- Validación de la suscripción : el agente valida los identificadores de suscripción en comandos para el formato GUID correcto antes de la ejecución.
Antes y después
En la tabla siguiente se compara el proceso de mitigación manual con el enfoque asistido por agente.
| antes de | después de | |
|---|---|---|
| Corrección de la ejecución | Vaya a Azure Portal, busque el recurso y haga clic en las hojas. | Preguntar al agente, aprobarlo, listo |
| Comprobación | Comprobar manualmente si se ha funcionado la corrección | El agente comprueba y notifica el resultado |
| Auditoría | Espero que alguien documente lo que hicieron | Registro de auditoría completo en Application Insights |
| Conocimiento | Un ingeniero conoce la corrección | El agente aplica patrones aprendidos de forma coherente |
Requisitos de permisos
De forma predeterminada, los agentes tienen acceso lector y no pueden realizar acciones. Para otorgar explícitamente permisos de escritura, asigne roles a la identidad administrada de su agente.
| Ámbito | Sobre qué puede actuar el agente | Recomendado para |
|---|---|---|
| Recurso | Solo un único recurso | Restricción máxima, comience aquí |
| Grupo de recursos | Todos los recursos de un grupo | Cargas de trabajo de producción |
| Subscription | Cualquier recurso de la suscripción | Solo desarrollo y pruebas |
Advertencia
El agente comprueba los bloqueos de administración de Azure antes de modificar cualquier recurso. No se pueden modificar los recursos con bloqueos ReadOnly, independientemente de los permisos o el modo de ejecución. Las operaciones de borrado y eliminación están completamente bloqueadas. Puede usar Azure Portal para eliminaciones.
Rutas de respuesta alternativas
Las mitigaciones directas no son la única opción. Muchos equipos prefieren enrutar los hallazgos a los elementos de trabajo o a los sistemas de gestión de tickets en lugar de ejecutar acciones directamente. Los elementos de trabajo son especialmente útiles cuando se requiere revisión humana o se aplican procesos de administración de cambios.
| Ruta de respuesta | Cómo funciona | Más adecuado para |
|---|---|---|
| Mitigación directa | El agente ejecuta el reinicio, el escalado o el endurecimiento | Patrones de confianza, no producción |
| Crear elemento de trabajo | El agente crea un problema de GitHub o un elemento de trabajo de Azure DevOps | Gestión de cambios con intervención humana |
| Enviar notificación | El agente publica en Teams o envía un correo electrónico | Reconocimiento sin acción |
| Activar flujo de trabajo | El agente envía acciones de GitHub o Logic Apps | Integración de CI/CD, procesos de varios pasos |
Configura la creación de elementos de trabajo y las notificaciones mediante conectores. Por ejemplo, conecte un servidor MCP de GitHub para permitir que el agente cree problemas o conecte Azure DevOps para crear elementos de trabajo automáticamente.
Para obtener más información, consulte Envío de notificaciones y automatización de flujos de trabajo para encadenar estos tipos de respuesta.
Ejemplo: mitigación desencadenada por incidentes
En el ejemplo siguiente se muestra cómo el agente gestiona un incidente de memoria a las 3:47 a. m. mientras duerme.
3:47 AM — PagerDuty dispara una alerta: "Alta memoria en prod-api"
El agente (en modo de revisión) controla todo lo siguiente:
Confirma el incidente : PagerDuty muestra "Confirmado por el agente de SRE".
Investiga automáticamente:
- Consultas de App Insights: memoria en 94%, con tendencia superior a 2 horas.
- Comprueba el historial de implementación: no hay implementaciones recientes.
- Recuerda: "La última vez que esto sucedió, reiniciar lo resolvió".
Propone una corrección — Publica en el subproceso de incidentes:
Memory at 94% on prod-api (App Service). Recommended action: Restart the App Service. Evidence: - Memory climbing since 1:30 AM - No recent deployments - Past incident: restart resolved similar issue on 2026-01-15 [Approve] [Deny]Aprueba (o en modo autónomo, el agente se ejecuta inmediatamente).
El agente ejecuta y comprueba lo siguiente:
✓ Restarted prod-api ✓ Memory now at 42% ✓ Incident resolved
Qué ha pasado: Hiciste clic en Aprobar y el agente gestionó la investigación, la acción y la comprobación.
Pista de auditoría
El sistema registra todas las acciones de mitigación junto con el contexto completo.
| Campo | Información capturada |
|---|---|
| Identidad | El agente y la identidad administrada |
| Acción | La operación exacta realizada |
| Timestamp | Cuando se ejecutó la operación |
| Trigger | Diagnóstico o condición que llevó a la acción |
| Result | Éxito o fracaso, con verificación posterior a la acción |
Puede consultar el registro de auditoría en Application Insights a través de Registros de Monitor > en el portal del agente. El sistema registra todos los az comandos como un AgentAzCliExecution evento personalizado. Para obtener más información, consulte Acciones de auditoría del agente.