paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
20 ops · Operation

SRE

SLOs, incidentes, postmortems.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El SRE es la persona que mantiene la producción honesta. En un SDLC AI-nativo, el SRE opera una pila de primitivas validadas, no un muro de dashboards.

Resumen ejecutivo

El SRE es responsable de la confiabilidad en producción: objetivos de nivel de servicio, respuesta a incidentes, operaciones de on-call, reducción de toil y postmortems. En un SDLC AI-nativo, el SRE opera dentro de la fase de Operation con un conjunto fijo de primitivas: un agente de incidentes, cuatro slash prompts, instrucciones con alcance, hooks validados por schema y una lista curada de MCPs validados. Los SLOs se definen en Azure Monitor, la comunicación de incidentes fluye por Microsoft Teams a través del M365 Agents SDK, y los postmortems viven como markdown versionado en GitHub. Las salidas primarias son definiciones de SLO, briefings de incidentes, documentos de postmortem y propuestas de reducción de toil.

Rol y responsabilidades

Piensa en el SRE como un médico de guardia de un hospital en el turno nocturno. No construye el hospital ni diseña los tratamientos, pero cuando un paciente entra en crisis lidera la sala: triage, estabiliza, diagnostica, documenta y alimenta los aprendizajes en el protocolo. La medida de un médico de guardia no son los heroísmos en una sola noche; es la tasa con la que la misma crisis deja de ocurrir. En un SDLC AI-nativo, el hospital es la flota de producción, el paciente es el SLO, y el protocolo es la biblioteca de runbooks respaldada por primitivas agénticas.

Responsabilidades primarias:

  • Definir y mantener SLOs y presupuestos de error en workbooks de Azure Monitor
  • Liderar la respuesta a incidentes: triage, mitigación, comunicación, recuperación
  • Coordinar el on-call vía Microsoft Teams con el bot de incidentes basado en el M365 Agents SDK
  • Redactar postmortems en GitHub e impulsar los action items hasta su cierre
  • Reducir el toil mediante automatización de runbooks y enforcement de hooks
  • Colaborar con el DevOps Engineer y el Release Manager en seguridad de despliegue
  • Operar el agente Incident Captain y los prompts /slo-review, /incident-brief, /postmortem-draft, /toil-scan

Jobs to be done

  1. Como SRE, quiero que los SLOs se revisen mensualmente con el burn del presupuesto de error, para que la confiabilidad sea un presupuesto, no un estado de ánimo.
  2. Como SRE, quiero un brief de incidente redactado en los primeros 5 minutos, para que los responders trabajen desde el mismo entendimiento.
  3. Como SRE, quiero postmortems redactados a partir de la telemetría del incidente, para que el documento se escriba solo mientras los humanos se enfocan en los action items.
  4. Como SRE, quiero el toil escaneado de forma continua, para que el trabajo manual repetitivo se convierta en código, no se absorba.
  5. Como SRE, quiero runbooks ejecutables desde el bot de incidentes en Teams, para que la mitigación sea una conversación, no una caza por la wiki.
  6. Como SRE, quiero que la misma clase de incidente nunca se repita, para que el backlog de action items sea corto y se cierre.

Dolores antes del AI-nativo

  1. SLOs como eslóganes. Cada servicio reclama 99,9 por ciento; nadie computa el burn. La primera caída real expone la mentira.
  2. Caos en incidentes. Los primeros 15 minutos son “quién está viendo qué”. Los hechos se recogen en Slack y se pierden cuando el hilo desaparece.
  3. Postmortems tardíos y delgados. Escritos dos semanas después, firmados sin action items, archivados en una carpeta que nadie lee.
  4. Toil invisible. Los ingenieros queman tardes reiniciando pods y rotando certificados. Nadie lo mide; nadie le asigna presupuesto.
  5. Runbooks podridos. El runbook era correcto hace tres arquitecturas. Los responders lo saltan e improvisan.

Flujo diario AI-nativo

El SRE opera un loop fijo cada día. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, además de un pequeño catálogo de MCPs validados para contexto externo.

Setup matinal

  1. Abre el repo de confiabilidad en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y las .github/instructions/reliability.instructions.md con alcance.
  2. En Claude Code, ejecuta el briefing diario de confiabilidad que consulta el Azure MCP por las últimas 24 horas de burn de SLO, alertas de Azure Monitor y anomalías de Application Insights.
  3. Revisa el backlog abierto de incidentes y el aging de action items en GitHub Projects.
  4. Confirma el calendario de on-call del día en Microsoft Teams.

Ejecución al mediodía

Cada ciclo de mediodía es una mejora de confiabilidad o un drill planeado de incidentes, típicamente de 2 a 3 horas de trabajo enfocado.

  1. Revisión de SLOs. Invoca /slo-review mensualmente para recalcular presupuestos de error, identificar servicios que queman más rápido de lo esperado y marcar SLOs que ya no son significativos.
  2. Escaneo de toil. Invoca /toil-scan para leer las ejecuciones de runbooks e intervenciones manuales del sprint anterior. El agente propone automatizaciones, priorizadas por horas ahorradas.
  3. Actualización de runbooks. Edita los runbooks afectados por cambios recientes de arquitectura; el hook pre-merge valida el schema del runbook y los dashboards enlazados.
  4. Pull request. Abre PRs para cambios de SLO, actualizaciones de runbook y automatización de reducción de toil. GitHub Copilot Code Review escanea los diffs.

Respuesta a incidentes por la tarde (cuando se dispara un incidente)

  1. Brief. Cuando Azure Monitor dispara una alerta de breach de SLO, el bot de incidentes basado en el M365 Agents SDK abre un canal en Teams e invoca /incident-brief. El agente Incident Captain produce un brief de 5 minutos a partir de alertas, despliegues recientes y errores de Application Insights.
  2. Estabilizar. Los responders siguen el runbook enlazado; los comandos de mitigación se ejecutan desde el bot de incidentes con audit trail en el canal de Teams.
  3. Comunicar. Las actualizaciones de estado se publican en Teams con cadencia (5 min para alta severidad, 15 min para media). Los stakeholders leen el canal, no correos separados.
  4. Postmortem. En las 48 horas siguientes a la resolución, invoca /postmortem-draft para producir una línea de tiempo, factores contribuyentes y action items desde la telemetría del incidente. El SRE edita la narrativa y asigna dueños en GitHub Projects.

Primitivas recomendadas

Agentes

AgenteArchivoPropósito
incident-captain.github/agents/incident-captain.agent.mdLiderar brief de incidente, draft de postmortem, revisión de SLO y escaneo de toil

El agente Incident Captain usa claude-sonnet-4-6 por defecto. Mantiene las herramientas read, edit, search, grep, glob, bash, y bindings MCP a Azure MCP, GitHub MCP y Microsoft 365 Agents SDK MCP. Extended thinking está habilitado para el razonamiento causal del postmortem.

Prompts

ComandoArchivoPropósito
/slo-review.github/prompts/slo-review.prompt.mdRevisar el burn del presupuesto de error y marcar SLOs que necesitan revisión
/incident-brief.github/prompts/incident-brief.prompt.mdProducir un brief de incidente de 5 minutos desde alertas, despliegues recientes y errores
/postmortem-draft.github/prompts/postmortem-draft.prompt.mdRedactar el postmortem desde telemetría de incidente, conversación y logs de ejecución de runbook
/toil-scan.github/prompts/toil-scan.prompt.mdIdentificar toil del sprint anterior y proponer automatizaciones priorizadas por horas ahorradas

Instrucciones

applyTo con alcance reduce el costo en tokens aproximadamente un 68 por ciento comparado con instrucciones globales.

Alcance (applyTo)ArchivoPropósito
slo/**/*.yaml.github/instructions/slo.instructions.mdSchema de definición de SLO, ventanas de burn rate, políticas de presupuesto
runbooks/**/*.md.github/instructions/runbook.instructions.mdFormato del runbook: síntomas, chequeos, mitigaciones, validaciones
postmortems/**/*.md.github/instructions/postmortem.instructions.mdPlantilla de postmortem sin culpa, disciplina de action items

Skills

Los skills se cargan bajo demanda, así que el SRE puede instalar muchos y pagar tokens solo por los que disparan.

  • burn-rate-reader: llama al Azure MCP para computar alertas multi-ventana multi-burn-rate sobre SLOs
  • action-item-tracker: garantiza que cada action item de postmortem se abra como issue de GitHub con dueño y fecha límite

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobernanza más fuerte.

  • pre-commit: validar schema YAML de SLO y frontmatter de runbook
  • pre-merge: requerir issues de action items enlazados en cada postmortem mergeado
  • post-incident: abrir el PR del draft de postmortem dentro de las 48 horas, escalar si no se mergea en 7 días

MCPs validados

Cada MCP a continuación está registrado en el catálogo de MCPs. No referencies ningún MCP que no esté en el catálogo.

MCPEstadoUso en esta persona
Azure MCP ServerOficial (Microsoft)Consultar Azure Monitor, Application Insights y Log Analytics para burn de SLO, alertas y telemetría de incidentes
GitHub MCP ServerOficialAbrir PRs de postmortem, rastrear action items, leer historial de despliegues
Microsoft 365 Agents SDK MCPOficial (Microsoft)Operar el bot de incidentes en Teams: creación de canal, actualizaciones de estado, audit de ejecución de runbook
Azure DevOps MCP ServerOficial (Microsoft)Leer pipelines de release y enlazar incidentes a release trains
Microsoft Learn Docs MCPOficialTraer guía de referencia de confiabilidad y observabilidad de Azure al redactar runbooks
Playwright MCPOficial (Microsoft)Ejecutar probes sintéticos desde el bot de incidentes para validar la recuperación

Ejemplos reales

Escenario A: se dispara un incidente p0 en latencia de checkout

Entrada: Azure Monitor dispara una alerta de burn rate de 2 horas en el SLO de checkout (99,9 por ciento de éxito, 300 ms p95). Application Insights muestra 4x la tasa de errores en el CheckoutController.

Invocación: El bot de incidentes en Teams invoca automáticamente /incident-brief cuando se dispara la alerta.

Salida esperada:

  1. Un canal de Teams inc-2026-04-24-checkout-latency creado en menos de 60 segundos.
  2. Un brief de incidente publicado: burn actual del SLO, últimos 3 despliegues (servicio y dependencias), top 5 firmas de error de Application Insights, runbook enlazado.
  3. Los responders ejecutan el paso de mitigación (“escalar a 2x, apagar el feature flag new-pricing-engine”) desde el bot con audit trail.
  4. Actualizaciones de estado cada 5 minutos durante los primeros 30 minutos; incidente resuelto en 42 minutos.

Escenario B: redactar un postmortem

Entrada: El incidente de checkout del Escenario A está resuelto. El SRE invoca /postmortem-draft a la mañana siguiente.

Invocación: /postmortem-draft con el ID del canal del incidente.

Salida esperada:

  1. Un postmortem postmortems/2026-04-24-checkout-latency.md con línea de tiempo, factores contribuyentes, impacto y action items propuestos.
  2. Cinco action items abiertos como issues de GitHub, cada uno con dueño y fecha límite, agrupados por tema (observabilidad, seguridad de rollout, automatización de rollback).
  3. Un enlace al release train relacionado y al feature flag que se apagó durante la mitigación.
  4. Un PR draft que el SRE edita por narrativa antes de mergear.

Anti-patrones

  1. SLOs sin alertas de burn rate. SLOs definidos pero nada alerta hasta que el presupuesto se consume por completo. Mitigación: alertas multi-ventana multi-burn-rate vía el skill burn-rate-reader.
  2. Respuesta heroica a incidentes. Un ingeniero senior en sus DMs corrige cada incidente. Mitigación: el bot de incidentes en Teams enforza brief, canal y audit trail para cada p0 y p1.
  3. Postmortems archivados, no leídos. Escritos, firmados, ignorados. Mitigación: action-item-tracker garantiza que cada postmortem abra issues reales con dueños y fechas límite.
  4. Toil absorbido. Los ingenieros rotan certificados y reinician pods sin registrarlo. Mitigación: /toil-scan lee los logs de ejecución de runbooks y propone automatizaciones.
  5. Drift de runbooks. Los runbooks describen una arquitectura vieja. Mitigación: el hook pre-merge valida el schema del runbook y que los dashboards enlazados retornen 200.

KPIs y métricas de impacto

La persona SRE se evalúa con una mezcla de métricas SRE y DORA.

MétricaBaseline (manual)Objetivo (agéntico)Medición
Cobertura de SLO30 por ciento de servicios> 95 por cientoServicios con SLOs definidos en Azure Monitor
Visibilidad de burn de presupuesto de errorSemanalContinuaDashboards de burn rate por servicio
Latencia de brief de incidente30 min< 5 minTiempo desde disparo de alerta hasta brief publicado
Tiempo medio de mitigación90 min< 30 minDuración del incidente en Azure Monitor
Tiempo medio de restauración4 horas< 1 horaRecuperación completa al SLO
Tasa de finalización de postmortem50 por ciento> 95 por cientoIncidentes con postmortem mergeado en 7 días
Tasa de cierre de action items40 por ciento> 80 por cientoAction items cerrados en el trimestre
Porcentaje de toil50 por ciento< 25 por cientoHoras de on-call en intervenciones manuales

Madurez en cuatro niveles

NivelNombreMarcadores
L1ManualSLOs como eslóganes, incidentes gestionados en hilos de Slack, postmortems opcionales
L2AsistidoGitHub Copilot ayuda a redactar postmortems, algunos SLOs definidos, sin bot de incidentes
L3AumentadoUn agente Incident Captain, cuatro slash prompts, instrucciones con alcance, MCPs de Azure y M365, bot de incidentes activo
L4AgénticoKit completo de primitivas, hooks enforzados, cobertura de SLO > 95 por ciento, brief de incidente en < 5 min, action items cerrados > 80 por ciento

Integración con otras personas

Entregas:

  • Del Release Manager: release train, niveles de riesgo, plan de rollback, reporte de canary
  • Del DevOps Engineer: artefacto desplegado, dashboards, reglas de alerta
  • Al Developer: hallazgos de incidente y action items como issues con pasos de reproducción
  • Al Platform Architect: resultados del escaneo de toil alimentan el roadmap de la matriz de capacidades
  • Al InfoSec Officer: incidentes clasificados como de seguridad son co-propiedad, con un postmortem conjunto

Glosario

  • Agente: un rol de LLM configurado con herramientas, instrucciones y un shape de salida definido.
  • Prompt: un slash command reutilizable que invoca un agente con una tarea específica.
  • Instrucciones: guía con alcance aplicada por pattern match en paths de archivo vía applyTo.
  • Skill: capacidad cargada bajo demanda que se activa por match de palabra clave.
  • Hook: regla de cero tokens enforzada en un evento específico del ciclo de vida.
  • MCP: servidor Model Context Protocol que expone sistemas externos al agente.
  • SLO: Service Level Objective, el objetivo de confiabilidad (p. ej., 99,9 por ciento de éxito a 300 ms p95).
  • Presupuesto de error: la falta de confiabilidad permitida derivada del SLO (p. ej., 0,1 por ciento en 28 días).
  • Burn rate: la tasa a la que se consume el presupuesto de error; alertado en multi-ventana multi-burn-rate.
  • Toil: trabajo operacional manual, repetitivo y automatizable que escala linealmente con el crecimiento del servicio.
  • Postmortem: documento sin culpa que captura línea de tiempo, factores contribuyentes, impacto y action items.

Referencias