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

SRE

SLOs, incidentes, postmortems.

Atualizado: 2026-04-24 14 seções Baixar .zip

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