Paula Silva Software Global Black Belt
LinkedIn
20 ops · Operation

SRESRESRE

SLOs, incidents, postmortems.SLOs, incidentes, postmortems.SLOs, incidentes, postmortems.

2026-04-24 14 sections Download the GitHub Copilot kitBaixar o kit do GitHub CopilotDescargar el kit de GitHub Copilot

The SRE is the persona that keeps production honest. In an AI-native SDLC, the SRE operates a stack of validated primitives, not a wall of dashboards.

Executive summary

The SRE owns production reliability: service level objectives, incident response, on-call operations, toil reduction, and postmortems. In an AI-native SDLC, the SRE operates inside the Operation phase with a fixed set of primitives: one incident agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. SLOs are defined in Azure Monitor, incident communication flows through Microsoft Teams via the M365 Agents SDK, and postmortems live as versioned markdown in GitHub. The primary outputs are SLO definitions, incident briefs, postmortem documents, and toil reduction proposals.

Role and responsibilities

Think of the SRE like a hospital attending physician on night shift. They do not build the hospital, nor design the treatments, but when a patient crashes they lead the room: triage, stabilize, diagnose, document, and feed the learnings into protocol. The measure of an attending is not heroics on a single night; it is the rate at which the same crisis stops happening. In an AI-native SDLC, the hospital is the production estate, the patient is the SLO, and the protocol is the runbook library backed by agentic primitives.

Primary responsibilities:

  • Define and maintain SLOs and error budgets in Azure Monitor workbooks
  • Lead incident response: triage, mitigation, communication, recovery
  • Coordinate on-call via Microsoft Teams with the M365 Agents SDK-backed incident bot
  • Author postmortems in GitHub and drive the action items to closure
  • Reduce toil through runbook automation and hook enforcement
  • Partner with DevOps Engineer and Release Manager on deployment safety
  • Operate the Incident Captain agent and the /slo-review, /incident-brief, /postmortem-draft, /toil-scan prompts

Jobs to be done

  1. As an SRE, I want SLOs reviewed monthly with error budget burn, so that reliability is a budget, not a mood.
  2. As an SRE, I want an incident brief drafted in the first 5 minutes, so that responders work from the same understanding.
  3. As an SRE, I want postmortems drafted from incident telemetry, so that the document writes itself while humans focus on action items.
  4. As an SRE, I want toil scanned continuously, so that repetitive manual work is converted to code, not absorbed.
  5. As an SRE, I want runbooks executable from the incident bot in Teams, so that mitigation is a conversation, not a wiki hunt.
  6. As an SRE, I want the same incident class to never ship twice, so that the action item backlog is short and closed.

Pain points before AI-native

  1. SLOs as slogans. Every service claims 99.9 percent; nobody computes burn. The first real outage exposes the lie.
  2. Incident chaos. The first 15 minutes are “who is seeing what.” Facts are collected on Slack, lost when the thread scrolls.
  3. Postmortems late and thin. Written two weeks later, signed off without action items, filed in a folder nobody reads.
  4. Toil invisible. Engineers burn afternoons restarting pods and rotating certs. Nobody measures it; nobody budgets against it.
  5. Runbooks rot. The runbook was correct three architectures ago. Responders skip it and improvise.

AI-native daily workflow

The SRE operates a fixed loop each day. The loop uses GitHub Copilot primitives inside Visual Studio Code and Claude Code at the terminal, plus a small catalog of validated MCPs for external context.

Morning setup

  1. Open the reliability repo in Visual Studio Code. GitHub Copilot Chat loads AGENTS.md and the scoped .github/instructions/reliability.instructions.md.
  2. In Claude Code, run the daily reliability briefing that queries the Azure MCP for the previous 24 hours of SLO burn, Azure Monitor alerts, and Application Insights anomalies.
  3. Review the open incident backlog and action item aging in GitHub Projects.
  4. Confirm the on-call schedule for the day in Microsoft Teams.

Midday execution

Each midday cycle is a single reliability improvement or planned incident drill, typically 2 to 3 hours of focused work.

  1. SLO review. Invoke /slo-review monthly to recompute error budgets, identify services burning faster than expected, and flag SLOs that are no longer meaningful.
  2. Toil scan. Invoke /toil-scan to read the previous sprint’s runbook executions and manual interventions. The agent proposes automations, prioritized by hours saved.
  3. Runbook update. Edit the runbooks affected by recent architecture changes; the pre-merge hook validates the runbook schema and the linked dashboards.
  4. Pull request. Open PRs for SLO changes, runbook updates, and toil reduction automation. GitHub Copilot Code Review scans diffs.

Afternoon incident response (when an incident fires)

  1. Brief. When Azure Monitor fires an SLO-breaching alert, the M365 Agents SDK-backed incident bot opens a Teams channel and invokes /incident-brief. The Incident Captain agent produces a 5-minute brief from alerts, recent deploys, and Application Insights errors.
  2. Stabilize. Responders follow the linked runbook; mitigation commands are executed from the incident bot with audit trail in the Teams channel.
  3. Communicate. Status updates are posted to Teams on a cadence (5 min for high-severity, 15 min for medium). Stakeholders read the channel, not separate emails.
  4. Postmortem. Within 48 hours of resolution, invoke /postmortem-draft to produce a timeline, contributing factors, and action items from the incident telemetry. The SRE edits for narrative and assigns owners in GitHub Projects.

Agents

AgentFilePurpose
incident-captain.github/agents/incident-captain.agent.mdLead incident brief, postmortem draft, SLO review, and toil scan

The Incident Captain agent uses claude-sonnet-4-6 by default. It holds tools read, edit, search, grep, glob, bash, and MCP bindings to Azure MCP, GitHub MCP, and Microsoft 365 Agents SDK MCP. Extended thinking is enabled for postmortem causal reasoning.

Prompts

CommandFilePurpose
/slo-review.github/prompts/slo-review.prompt.mdReview error budget burn and flag SLOs that need revision
/incident-brief.github/prompts/incident-brief.prompt.mdProduce a 5-minute incident brief from alerts, recent deploys, and errors
/postmortem-draft.github/prompts/postmortem-draft.prompt.mdDraft the postmortem from incident telemetry, conversation, and runbook execution logs
/toil-scan.github/prompts/toil-scan.prompt.mdIdentify toil from the previous sprint and propose automations prioritized by hours saved

Instructions

Scoped applyTo reduces token cost by approximately 68 percent compared to global instructions.

Scope (applyTo)FilePurpose
slo/**/*.yaml.github/instructions/slo.instructions.mdSLO definition schema, burn rate windows, budget policies
runbooks/**/*.md.github/instructions/runbook.instructions.mdRunbook format: symptoms, checks, mitigations, validations
postmortems/**/*.md.github/instructions/postmortem.instructions.mdBlameless postmortem template, action item discipline

Skills

Skills are lazy-loaded, so the SRE can install many and pay tokens only for the ones that trigger.

  • burn-rate-reader: calls the Azure MCP to compute multi-window multi-burn-rate alerts on SLOs
  • action-item-tracker: ensures every postmortem action item is opened as a GitHub issue with owner and due date

Hooks

Hooks cost zero LLM tokens. They are the strongest governance layer.

  • pre-commit: validate SLO YAML schema and runbook front matter
  • pre-merge: require action item issues linked on every merged postmortem
  • post-incident: open the postmortem draft PR within 48 hours, escalate if not merged within 7 days

Validated MCPs

Every MCP below is registered in the MCP catalog. Do not reference any MCP that is not in the catalog.

MCPStatusUse in this persona
Azure MCP ServerOfficial (Microsoft)Query Azure Monitor, Application Insights, Log Analytics for SLO burn, alerts, and incident telemetry
GitHub MCP ServerOfficialOpen postmortem PRs, track action items, read deploy history
Microsoft 365 Agents SDK MCPOfficial (Microsoft)Operate the incident bot in Teams: channel creation, status updates, runbook execution audit
Azure DevOps MCP ServerOfficial (Microsoft)Read release pipelines and link incidents to release trains
Microsoft Learn Docs MCPOfficialFetch Azure reliability and observability reference guidance while authoring runbooks
Playwright MCPOfficial (Microsoft)Run synthetic probes from the incident bot to validate recovery

Real examples

Scenario A: a p0 incident fires on checkout latency

Input: Azure Monitor fires a 2-hour burn rate alert on the checkout SLO (99.9 percent success, 300 ms p95). Application Insights shows a 4x error rate on the CheckoutController.

Invocation: The incident bot in Teams auto-invokes /incident-brief on alert fire.

Expected output:

  1. A Teams channel inc-2026-04-24-checkout-latency created within 60 seconds.
  2. An incident brief posted: current SLO burn, last 3 deploys (service and dependency), top 5 error signatures from Application Insights, linked runbook.
  3. Responders execute the mitigation step (“scale out to 2x, flip feature flag new-pricing-engine off”) from the bot with audit trail.
  4. Status updates every 5 minutes for the first 30 minutes; incident resolved within 42 minutes.

Scenario B: draft a postmortem

Input: The checkout incident from Scenario A is resolved. The SRE invokes /postmortem-draft the next morning.

Invocation: /postmortem-draft with the incident channel ID.

Expected output:

  1. A postmortem postmortems/2026-04-24-checkout-latency.md with timeline, contributing factors, impact, and proposed action items.
  2. Five action items opened as GitHub issues, each with owner and due date, grouped by theme (observability, rollout safety, rollback automation).
  3. A link to the related release train and the feature flag that was flipped off during mitigation.
  4. A draft PR that the SRE edits for narrative before merging.

Anti-patterns

  1. SLOs without burn rate alerts. SLOs defined but nothing alerts until the budget is fully consumed. Mitigation: multi-window multi-burn-rate alerts via the burn-rate-reader skill.
  2. Heroic incident response. One senior engineer in their DMs fixes every incident. Mitigation: incident bot in Teams enforces brief, channel, and audit trail for every p0 and p1.
  3. Postmortems filed, not read. Written, signed, ignored. Mitigation: action-item-tracker ensures each postmortem opens real issues with owners and due dates.
  4. Toil absorbed. Engineers rotate certs and restart pods without logging. Mitigation: /toil-scan reads the runbook execution logs and proposes automations.
  5. Runbook drift. Runbooks describe an old architecture. Mitigation: pre-merge hook validates runbook schema and the linked dashboards return 200.

KPIs and impact metrics

The SRE persona is evaluated with a mix of SRE and DORA metrics.

MetricBaseline (manual)Target (agentic)Measurement
SLO coverage30 percent of services> 95 percentServices with defined SLOs in Azure Monitor
Error budget burn visibilityWeeklyContinuousBurn rate dashboards per service
Incident brief latency30 min< 5 minTime from alert fire to brief posted
Mean time to mitigate90 min< 30 minAzure Monitor incident duration
Mean time to restore4 hours< 1 hourFull recovery to SLO
Postmortem completion rate50 percent> 95 percentIncidents with merged postmortem within 7 days
Action item closure rate40 percent> 80 percentAction items closed within quarter
Toil percentage50 percent< 25 percentOn-call hours on manual interventions

Maturity in four levels

LevelNameMarkers
L1ManualSLOs as slogans, incidents managed in Slack threads, postmortems optional
L2AssistedGitHub Copilot helps draft postmortems, some SLOs defined, no incident bot
L3AugmentedOne Incident Captain agent, four slash prompts, scoped instructions, Azure and M365 MCPs, incident bot live
L4AgenticFull primitives kit, hooks enforced, SLO coverage > 95 percent, incident brief in < 5 min, action items closed > 80 percent

Integration with other personas

Handoffs:

  • From Release Manager: release train, risk tiers, rollback plan, canary report
  • From DevOps Engineer: deployed artifact, dashboards, alert rules
  • To Developer: incident findings and action items as issues with reproduction steps
  • To Platform Architect: toil scan results feed the capability matrix roadmap
  • To InfoSec Officer: incidents classified as security are co-owned, with a joint postmortem

Glossary

  • Agent: a configured LLM role with tools, instructions, and a defined output shape.
  • Prompt: a reusable slash command that invokes an agent with a specific task.
  • Instructions: scoped guidance applied by pattern match on file paths via applyTo.
  • Skill: a lazy-loaded capability that activates on keyword match.
  • Hook: a zero-token rule enforced at a specific lifecycle event.
  • MCP: Model Context Protocol server that exposes external systems to the agent.
  • SLO: Service Level Objective, the reliability target (e.g., 99.9 percent success at 300 ms p95).
  • Error budget: the allowed unreliability derived from the SLO (e.g., 0.1 percent over 28 days).
  • Burn rate: the rate at which error budget is being consumed; alerted on multi-window multi-burn-rate.
  • Toil: manual, repetitive, automatable operational work that scales linearly with service growth.
  • Postmortem: a blameless document capturing timeline, contributing factors, impact, and action items.

References

O SRE é a persona que mantém a produção honesta. Em um SDLC AI-nativo, o SRE opera uma pilha de primitivas validadas, não uma parede de dashboards.

Resumo executivo

O SRE é dono da confiabilidade em produção: objetivos de nível de serviço, resposta a incidentes, operações de plantão, redução de toil e postmortems. Em um SDLC AI-nativo, o SRE opera dentro da fase de Operação com um conjunto fixo de primitivas: um agente de incidente, quatro slash prompts, instruções com escopo, hooks validados por schema e uma lista curada de MCPs validados. SLOs são definidos no Azure Monitor, comunicação de incidentes flui através do Microsoft Teams via o M365 Agents SDK, e postmortems vivem como markdown versionado no GitHub. As saídas primárias são definições de SLO, briefs de incidente, documentos de postmortem e propostas de redução de toil.

Papel e responsabilidades

Pense no SRE como um médico plantonista de noite em um hospital. Ele não construiu o hospital, nem projetou os tratamentos, mas quando um paciente entra em crise ele lidera a sala: triagem, estabilização, diagnóstico, documentação e alimentação dos aprendizados no protocolo. A medida de um plantonista não é o heroísmo em uma única noite; é a taxa com que a mesma crise para de acontecer. Em um SDLC AI-nativo, o hospital é o patrimônio de produção, o paciente é o SLO, e o protocolo é a biblioteca de runbooks respaldada por primitivas agênticas.

Responsabilidades primárias:

  • Definir e manter SLOs e error budgets em workbooks do Azure Monitor
  • Liderar resposta a incidentes: triagem, mitigação, comunicação, recuperação
  • Coordenar plantão via Microsoft Teams com o bot de incidente respaldado pelo M365 Agents SDK
  • Redigir postmortems no GitHub e conduzir os action items até o fechamento
  • Reduzir toil através de automação de runbooks e enforcement de hooks
  • Parceria com o DevOps Engineer e o Release Manager em segurança de deploy
  • Operar o agente Incident Captain e os prompts /slo-review, /incident-brief, /postmortem-draft, /toil-scan

Jobs to be done

  1. Como SRE, eu quero SLOs revisados mensalmente com burn de error budget, para que confiabilidade seja um orçamento, não um humor.
  2. Como SRE, eu quero um brief de incidente redigido nos primeiros 5 minutos, para que os respondentes trabalhem a partir do mesmo entendimento.
  3. Como SRE, eu quero postmortems redigidos a partir de telemetria de incidente, para que o documento se escreva sozinho enquanto humanos focam em action items.
  4. Como SRE, eu quero toil escaneado continuamente, para que trabalho manual repetitivo seja convertido em código, não absorvido.
  5. Como SRE, eu quero runbooks executáveis a partir do bot de incidente no Teams, para que mitigação seja uma conversa, não uma caça na wiki.
  6. Como SRE, eu quero que a mesma classe de incidente nunca seja entregue duas vezes, para que o backlog de action items seja curto e fechado.

Dores antes do AI-nativo

  1. SLOs como slogans. Todo serviço alega 99,9 por cento; ninguém computa o burn. O primeiro outage real expõe a mentira.
  2. Caos de incidentes. Os primeiros 15 minutos são “quem está vendo o quê?” Fatos são coletados no Slack, perdidos quando a thread rola.
  3. Postmortems atrasados e rasos. Escritos duas semanas depois, assinados sem action items, arquivados em uma pasta que ninguém lê.
  4. Toil invisível. Engenheiros queimam tardes reiniciando pods e rotacionando certificados. Ninguém mede; ninguém orça contra isso.
  5. Runbooks apodrecidos. O runbook estava correto três arquiteturas atrás. Respondentes o ignoram e improvisam.

Fluxo diário AI-nativo

O SRE opera um loop fixo cada dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, mais um pequeno catálogo de MCPs validados para contexto externo.

Setup da manhã

  1. Abra o repo de confiabilidade no Visual Studio Code. GitHub Copilot Chat carrega AGENTS.md e as instruções com escopo .github/instructions/reliability.instructions.md.
  2. No Claude Code, rode o briefing diário de confiabilidade que consulta o Azure MCP para as últimas 24 horas de burn de SLO, alertas do Azure Monitor e anomalias do Application Insights.
  3. Revise o backlog de incidentes abertos e envelhecimento de action items no GitHub Projects.
  4. Confirme a escala de plantão do dia no Microsoft Teams.

Execução no meio do dia

Cada ciclo do meio do dia é uma melhoria de confiabilidade única ou simulação de incidente planejada, tipicamente 2 a 3 horas de trabalho focado.

  1. Revisão de SLO. Invoque /slo-review mensalmente para recalcular error budgets, identificar serviços queimando mais rápido que o esperado e sinalizar SLOs que não são mais significativos.
  2. Scan de toil. Invoque /toil-scan para ler as execuções de runbooks e intervenções manuais da sprint anterior. O agente propõe automações, priorizadas por horas economizadas.
  3. Atualização de runbook. Edite os runbooks afetados por mudanças recentes de arquitetura; o hook pre-merge valida o schema do runbook e os dashboards linkados.
  4. Pull request. Abra PRs para mudanças de SLO, atualizações de runbook e automação de redução de toil. GitHub Copilot Code Review escaneia diffs.

Resposta a incidentes na tarde (quando um incidente dispara)

  1. Brief. Quando o Azure Monitor dispara um alerta de violação de SLO, o bot de incidente respaldado pelo M365 Agents SDK abre um canal no Teams e invoca /incident-brief. O agente Incident Captain produz um brief de 5 minutos a partir de alertas, deploys recentes e erros do Application Insights.
  2. Estabilizar. Respondentes seguem o runbook linkado; comandos de mitigação são executados a partir do bot de incidente com trilha de auditoria no canal do Teams.
  3. Comunicar. Atualizações de status são postadas no Teams em cadência (5 min para alta severidade, 15 min para média). Stakeholders leem o canal, não emails separados.
  4. Postmortem. Em até 48 horas da resolução, invoque /postmortem-draft para produzir uma timeline, fatores contribuintes e action items a partir da telemetria do incidente. O SRE edita a narrativa e atribui donos no GitHub Projects.

Primitivas recomendadas

Agentes

AgenteArquivoPropósito
incident-captain.github/agents/incident-captain.agent.mdLiderar brief de incidente, rascunho de postmortem, revisão de SLO e scan de toil

O agente Incident Captain usa claude-sonnet-4-6 por padrão. Detém as ferramentas read, edit, search, grep, glob, bash e bindings de MCP para Azure MCP, GitHub MCP e Microsoft 365 Agents SDK MCP. Extended thinking é habilitado para raciocínio causal de postmortem.

Prompts

ComandoArquivoPropósito
/slo-review.github/prompts/slo-review.prompt.mdRevisar burn de error budget e sinalizar SLOs que precisam de revisão
/incident-brief.github/prompts/incident-brief.prompt.mdProduzir um brief de incidente de 5 minutos a partir de alertas, deploys recentes e erros
/postmortem-draft.github/prompts/postmortem-draft.prompt.mdRedigir o postmortem a partir de telemetria do incidente, conversa e logs de execução de runbook
/toil-scan.github/prompts/toil-scan.prompt.mdIdentificar toil da sprint anterior e propor automações priorizadas por horas economizadas

Instruções

applyTo com escopo reduz o custo em tokens em aproximadamente 68 por cento comparado a instruções globais.

Escopo (applyTo)ArquivoPropósito
slo/**/*.yaml.github/instructions/slo.instructions.mdSchema de definição de SLO, janelas de burn rate, políticas de budget
runbooks/**/*.md.github/instructions/runbook.instructions.mdFormato de runbook: sintomas, verificações, mitigações, validações
postmortems/**/*.md.github/instructions/postmortem.instructions.mdTemplate de postmortem blameless, disciplina de action items

Skills

Skills são carregadas sob demanda, então o SRE pode instalar muitas e pagar tokens só pelas que disparam.

  • burn-rate-reader: chama o Azure MCP para computar alertas multi-janela multi-burn-rate em SLOs
  • action-item-tracker: garante que cada action item de postmortem é aberto como uma issue do GitHub com dono e data-limite

Hooks

Hooks custam zero tokens de LLM. São a camada de governança mais forte.

  • pre-commit: validar schema YAML de SLO e front matter de runbook
  • pre-merge: exigir issues de action items linkadas em cada postmortem merged
  • post-incident: abrir o PR de rascunho de postmortem em até 48 horas, escalar se não merged em 7 dias

MCPs validados

Todo MCP abaixo está registrado no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.

MCPStatusUso nesta persona
Azure MCP ServerOficial (Microsoft)Consultar Azure Monitor, Application Insights, Log Analytics para burn de SLO, alertas e telemetria de incidentes
GitHub MCP ServerOficialAbrir PRs de postmortem, rastrear action items, ler histórico de deploys
Microsoft 365 Agents SDK MCPOficial (Microsoft)Operar o bot de incidente no Teams: criação de canal, atualizações de status, trilha de auditoria de execução de runbook
Azure DevOps MCP ServerOficial (Microsoft)Ler pipelines de release e linkar incidentes a trens de release
Microsoft Learn Docs MCPOficialBuscar orientação de confiabilidade e observabilidade do Azure ao redigir runbooks
Playwright MCPOficial (Microsoft)Rodar probes sintéticas a partir do bot de incidente para validar a recuperação

Exemplos reais

Cenário A: um incidente p0 dispara na latência do checkout

Entrada: Azure Monitor dispara um alerta de burn rate de 2 horas no SLO do checkout (99,9 por cento de sucesso, 300 ms p95). Application Insights mostra uma taxa de erro 4x no CheckoutController.

Invocação: O bot de incidente no Teams auto-invoca /incident-brief no disparo do alerta.

Saída esperada:

  1. Um canal no Teams inc-2026-04-24-checkout-latency criado em até 60 segundos.
  2. Um brief de incidente postado: burn atual do SLO, últimos 3 deploys (serviço e dependência), top 5 assinaturas de erro do Application Insights, runbook linkado.
  3. Respondentes executam o passo de mitigação (“escalar para 2x, desligar feature flag new-pricing-engine”) a partir do bot com trilha de auditoria.
  4. Atualizações de status a cada 5 minutos pelos primeiros 30 minutos; incidente resolvido em 42 minutos.

Cenário B: redigir um postmortem

Entrada: O incidente do checkout do Cenário A está resolvido. O SRE invoca /postmortem-draft na manhã seguinte.

Invocação: /postmortem-draft com o ID do canal de incidente.

Saída esperada:

  1. Um postmortem postmortems/2026-04-24-checkout-latency.md com timeline, fatores contribuintes, impacto e action items propostos.
  2. Cinco action items abertos como issues do GitHub, cada um com dono e data-limite, agrupados por tema (observabilidade, segurança de rollout, automação de rollback).
  3. Um link para o trem de release relacionado e a feature flag que foi desligada durante a mitigação.
  4. Um PR rascunho que o SRE edita a narrativa antes de fazer merge.

Anti-padrões

  1. SLOs sem alertas de burn rate. SLOs definidos mas nada alerta até o budget ser totalmente consumido. Mitigação: alertas multi-janela multi-burn-rate via o skill burn-rate-reader.
  2. Resposta heroica a incidentes. Um engenheiro sênior nas DMs resolve cada incidente. Mitigação: bot de incidente no Teams enforça brief, canal e trilha de auditoria para cada p0 e p1.
  3. Postmortems arquivados, não lidos. Escritos, assinados, ignorados. Mitigação: action-item-tracker garante que cada postmortem abre issues reais com donos e datas-limite.
  4. Toil absorvido. Engenheiros rotacionam certificados e reiniciam pods sem logar. Mitigação: /toil-scan lê os logs de execução de runbook e propõe automações.
  5. Drift de runbooks. Runbooks descrevem uma arquitetura antiga. Mitigação: hook pre-merge valida o schema do runbook e os dashboards linkados retornam 200.

KPIs e métricas de impacto

A persona SRE é avaliada com uma mistura de métricas SRE e DORA.

MétricaLinha base (manual)Meta (agêntico)Medição
Cobertura de SLO30 por cento dos serviços> 95 por centoServiços com SLOs definidos no Azure Monitor
Visibilidade do burn de error budgetSemanalContínuaDashboards de burn rate por serviço
Latência do brief de incidente30 min< 5 minTempo do disparo do alerta ao brief postado
Tempo médio de mitigação90 min< 30 minDuração do incidente no Azure Monitor
Tempo médio de restauração4 horas< 1 horaRecuperação completa até o SLO
Taxa de conclusão de postmortem50 por cento> 95 por centoIncidentes com postmortem merged em 7 dias
Taxa de fechamento de action items40 por cento> 80 por centoAction items fechados no trimestre
Percentual de toil50 por cento< 25 por centoHoras de plantão em intervenções manuais

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualSLOs como slogans, incidentes gerenciados em threads do Slack, postmortems opcionais
L2AssistidoGitHub Copilot ajuda a redigir postmortems, alguns SLOs definidos, sem bot de incidente
L3AumentadoUm agente Incident Captain, quatro slash prompts, instruções com escopo, MCPs do Azure e M365, bot de incidente ativo
L4AgênticoKit completo de primitivas, hooks enforçados, cobertura de SLO > 95 por cento, brief de incidente em < 5 min, action items fechados > 80 por cento

Integração com outras personas

Entregas:

  • Do Release Manager: trem de release, tiers de risco, plano de rollback, relatório de canário
  • Do DevOps Engineer: artefato deployado, dashboards, regras de alerta
  • Para o Developer: achados de incidente e action items como issues com passos de reprodução
  • Para o Platform Architect: resultados do scan de toil alimentam o roadmap da matriz de capacidades
  • Para o InfoSec Officer: incidentes classificados como segurança são co-owned, com postmortem conjunto

Glossário

  • Agente: um papel de LLM configurado com ferramentas, instruções e um shape de saída definido.
  • Prompt: um slash command reutilizável que invoca um agente com uma tarefa específica.
  • Instruções: orientação com escopo aplicada por pattern match em paths de arquivo via applyTo.
  • Skill: capacidade carregada sob demanda que ativa por match de palavra-chave.
  • Hook: regra de zero tokens enforçada em um evento específico de ciclo de vida.
  • MCP: servidor Model Context Protocol que expõe sistemas externos ao agente.
  • SLO: Service Level Objective, o alvo de confiabilidade (ex.: 99,9 por cento de sucesso a 300 ms p95).
  • Error budget: a indisponibilidade permitida derivada do SLO (ex.: 0,1 por cento em 28 dias).
  • Burn rate: a taxa com que o error budget está sendo consumido; alertado em multi-janela multi-burn-rate.
  • Toil: trabalho operacional manual, repetitivo e automatizável que escala linearmente com o crescimento do serviço.
  • Postmortem: um documento blameless capturando timeline, fatores contribuintes, impacto e action items.

Referências

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

Paula Silva | Software Global Black Belt

Start with the platform, not the agents. Comece pela plataforma, não pelos agentes. Comience por la plataforma, no por los agentes.

Building the future of software development with AI and Agentic DevOps.

Knowledge Hub · v3.4.0 · 2026-06-17
Back to the hubVoltar ao hubVolver al hubKnowledge HubKnowledge HubKnowledge Hub
ConnectConectarConectarin/paulanunes
paulasilva · 2026-06-17 EN · PT-BR · ES