Gestão de incidentes para SaaS: runbooks, plantão e post-mortems

Todo produto SaaS vai ter incidentes. A diferença entre uma noite ruim e um cliente perdido raramente está no bug em si; está em quão rápido alguém percebeu, se sabia o que fazer e quão claramente você se comunicou enquanto o problema acontecia. A gestão de incidentes é o conjunto de hábitos que torna essas coisas previsíveis: uma definição compartilhada de severidade, uma escala de plantão que não esgota as pessoas, runbooks que respondem às primeiras perguntas, um plano de comunicação e post-mortems que tornam o próximo incidente menos provável. Este guia cobre cada um deles para um time pequeno que mantém software em produção, não para operações de segurança nem serviços de emergência.

O que a gestão de incidentes cobre: as cinco etapas

Incidente é qualquer evento não planejado que degrada seu serviço para os usuários ou o coloca em risco. A gestão de incidentes de software é o processo desde o momento em que algo dá errado até o momento em que você aprendeu com o ocorrido:

1. Detectar: o monitoramento ou um cliente avisa que algo está errado.
2. Triar: decidir quão grave é e quem precisa ser envolvido.
3. Responder: primeiro mitigar, depois corrigir.
4. Comunicar: manter o time, a liderança e os clientes informados.
5. Aprender: escrever o post-mortem e cumprir as ações definidas.

O livro de SRE do Google sugere uma regra útil para saber quando declarar um incidente formalmente: se você precisa de um segundo time, se os clientes enxergam o problema ou se ele continua sem solução depois de uma hora de trabalho focado. Declarar cedo custa pouco. Declarar tarde significa que a resposta será improvisada.

Defina os níveis de severidade antes de precisar deles

Os níveis de severidade decidem quem é acordado e com que rapidez. Combine-os com calma, escreva e mantenha poucos. Um ponto de partida para um time pequeno de SaaS, com exemplos de gestão de incidentes para cada nível:

Nível	Significado	Exemplo	Resposta
SEV-1	Produto fora do ar ou dados em risco para muitos clientes	O login falha para todo mundo; perda de dados	Acionar na hora, todos a postos, atualizações aos clientes
SEV-2	Funcionalidade importante quebrada ou muito degradada	Erros no checkout para boa parte dos usuários	Acionar o plantão, atualizações aos clientes afetados
SEV-3	Degradação parcial com solução alternativa	Uma integração atrasada; relatórios lentos	No próximo horário comercial, ticket
SEV-4	Problema menor, sem impacto real nos usuários	Bug cosmético; alerta ruidoso	Backlog

A PagerDuty publica suas próprias definições de níveis de severidade, uma boa referência se você quiser mais detalhes. Ela também traz a regra isolada mais útil nessa área: em dúvida entre dois níveis, trate como o mais alto e resolva a classificação no post-mortem, não durante o incidente.

Como desenhar uma escala de plantão para um time pequeno

A escala de plantão é onde os planos de resposta a incidentes encontram pessoas de verdade, e onde os times pequenos mais erram. A falha mais comum é o CTO ou um engenheiro sênior estar sempre de plantão porque ninguém mais conhece o sistema.

A orientação do Google dá uma noção de escala. O SRE workbook diz que uma cobertura 24/7 sustentável exige pelo menos oito engenheiros em um único site, ou cinco por site em dois sites, e define como meta no máximo dois incidentes por turno de 12 horas. A maioria das startups está longe desse número de pessoas em operações, então precisa se organizar de outro jeito.

Princípios que funcionam para times pequenos:

• Use primário e secundário. O primário responde; o secundário é o reserva se o primário não confirmar o chamado em um prazo definido. A escalação deve ser automática, não uma árvore de telefonemas.
• Alterne por semana e faça a passagem de bastão de propósito. Uma nota curta de passagem, com pendências abertas, deploys recentes e qualquer coisa instável, poupa uma hora da próxima pessoa.
• Acione apenas o que precisa de um humano agora. Todo alerta deve ser acionável e ligado a impacto para o usuário. O resto vai para um canal ou ticket para o horário comercial. A fadiga de alertas é o que faz os alertas reais serem ignorados.
• Proteja quem está de plantão. Menos trabalho de projeto na semana de plantão, folga depois de uma noite ruim e remuneração pelo trabalho fora do horário. O workbook do Google diz que o trabalho fora do expediente deve ser remunerado.
• Meça a carga. Conte os acionamentos por semana e por turno. Se um serviço gera a maior parte deles, corrigi-lo é o melhor trabalho de confiabilidade que você pode fazer.

Se você não consegue montar internamente uma escala justa, é sinal de que vale dividir a carga com um time externo em vez de espalhá-la ainda mais entre seus desenvolvedores.

Runbooks: responda aos primeiros dez minutos

Um runbook é um documento curto, ligado a um alerta, que diz a quem responde o que o alerta significa e o que verificar primeiro. Bons runbooks transformam um chamado das 3h da manhã de um projeto de pesquisa em um checklist.

Todo alerta deve apontar para um runbook com:

• O que o alerta significa, em linguagem simples, e por que importa para os usuários.
• Como confirmá-lo: o dashboard, a consulta, a busca nos logs.
• Causas prováveis, começando pelas mais comuns: um deploy recente, uma dependência, capacidade.
• Primeiras ações seguras: rollback, escalar horizontalmente, fazer failover, reiniciar, com os comandos exatos.
• Quando escalar e para quem.

Mantenha os runbooks em controle de versão, ao lado do código ou da infraestrutura que descrevem, e revise-os após cada incidente que usou um deles. Um alerta sem runbook é trabalho inacabado. Um runbook que não é tocado há um ano provavelmente está errado.

Papéis e responsabilidades na gestão de incidentes

Quem responde conserta o sistema; outra pessoa deve cuidar da comunicação. O modelo de incidentes do Google separa a resposta em quatro papéis: comando do incidente, que mantém o estado geral e dirige a resposta; operações, que aplica as correções; comunicação, que mantém os stakeholders atualizados; e planejamento, que cuida do trabalho de mais longo prazo, como abrir bugs e organizar passagens de bastão. Em um time pequeno, uma pessoa pode acumular dois deles, mas definir quem está no comando e quem atualiza os stakeholders evita a falha clássica em que todo mundo investiga e ninguém avisa os clientes.

Comunicação durante um incidente

Hábitos práticos:

• Um canal por incidente, para que a linha do tempo fique num só lugar.
• Atualizações regulares num horário fixo, mesmo quando a atualização é “ainda investigando”. Para um SEV-1, a cada 30 minutos é um padrão razoável.
• Uma página de status pública para incidentes que afetam clientes, com modelos escritos de antemão.
• Linguagem simples. Diga o que os usuários estão vivendo, o que você está fazendo e quando virá a próxima atualização. Evite especular sobre causas em público.

Post-mortems sem culpados

Depois do incidente, escreva o que aconteceu. O Google define um post-mortem sem culpados como aquele que se concentra “em identificar as causas contribuintes do incidente sem acusar nenhuma pessoa ou time de comportamento ruim ou inadequado.” A premissa é que as pessoas tomaram decisões razoáveis com as informações que tinham. Se alguém consegue derrubar a produção com um único comando, o problema é o sistema que permitiu isso.

Decida de antemão quais incidentes geram um post-mortem. A lista do Google é um bom começo: indisponibilidade visível para o usuário acima de um limite, qualquer perda de dados, uma intervenção do plantão como um rollback, um tempo longo de resolução ou uma falha de monitoramento em que uma pessoa encontrou o problema primeiro.

Um bom post-mortem tem:

1. Resumo e impacto: o que aconteceu, quem foi afetado, por quanto tempo.
2. Linha do tempo: detecção, decisões-chave, mitigação, resolução.
3. Causas contribuintes: geralmente várias, técnicas e de processo.
4. O que funcionou bem e o que foi sorte.
5. Itens de ação com responsável e data.

Os itens de ação são a única parte que muda alguma coisa. Acompanhe-os como qualquer outro trabalho de engenharia e revise os que continuam abertos todo mês. Um post-mortem cujas ações nunca saem do papel é uma entrada de diário.

Um plano mínimo de resposta a incidentes

Se hoje você não tem nada, isto basta para começar:

• Quatro níveis de severidade, por escrito.
• Plantão com primário e secundário e escalação automática.
• Alertas sobre sintomas visíveis ao usuário, cada um ligado a um runbook.
• Um modelo de canal de incidente e uma página de status.
• Um modelo de post-mortem e uma regra para quando usá-lo.

Cada um deles pode ser montado em uma semana. Melhore-os depois de cada incidente real.

Perguntas frequentes

O que se entende por gestão de incidentes?

Gestão de incidentes é o processo que um time segue desde o momento em que um serviço se degrada ou fica em risco até ter aprendido com o evento. Para um time de SaaS, cobre níveis de severidade, plantão, runbooks, comunicação com os clientes e post-mortems. O objetivo é tornar a resposta previsível em vez de improvisada.

Quais são as 5 etapas da gestão de incidentes?

Uma versão prática para times de software é detectar, triar, responder, comunicar e aprender. Você percebe o problema pelo monitoramento ou por um cliente, decide a gravidade, mitiga antes de corrigir, mantém as pessoas informadas o tempo todo e termina com um post-mortem sem culpados cujos itens de ação realmente saem do papel.

Quem faz o quê durante um incidente?

O modelo do Google define quatro papéis: comando do incidente, operações, comunicação e planejamento. O comandante do incidente coordena e toma as decisões, operações trabalha no sistema, comunicação cuida das atualizações e planejamento trata do trabalho de acompanhamento. Em um time pequeno, uma pessoa muitas vezes acumula dois papéis, desde que todos saibam quem está no comando.

Onde entram os agentes e os engenheiros

Boa parte da gestão de incidentes é vigiar, rotear e reunir contexto, trabalho que as máquinas fazem bem e que os humanos fazem mal às 3h da manhã. Julgamento, correções e comunicação com o cliente são trabalho humano.

Na Webera, o Sentinel monta o monitoramento, detecta anomalias e cria regras de alerta com runbooks. O Dispatcher desenha escalas de plantão e políticas de escalação, roteia incidentes por severidade e responsável pelo serviço, filtra alertas ruidosos e cria playbooks de resposta a incidentes. O Warden confere se todo alerta tem um runbook antes de o monitoramento 24/7 entrar no ar. Então um engenheiro sênior de plantão lê o contexto, toma a decisão e entrega a correção. A IA é boa na primeira análise e ainda não é confiável para encontrar causas-raiz sozinha, ponto que abordamos em engenharia de confiabilidade (SRE) vs. DevOps. Incidentes e custos também se encontram: o rightsizing agressivo é uma causa comum dos dois, como explica nosso playbook de otimização de custos na AWS.

Tire o pager das costas dos seus desenvolvedores

A Webera é uma assinatura de DevOps para times de SaaS na AWS. Todos os planos incluem monitoramento 24/7 e resposta a incidentes, solicitações ilimitadas e os nove agentes. O Pro custa US$ 4.999 por mês, o Elite US$ 9.999 com engenheiro designado e o Platform US$ 14.999 com um time dentro das suas sprints. Cada um tem mínimo de três meses e, depois, mês a mês, e todo o código e toda a configuração são seus.

Se o seu CTO ainda é a escala de plantão, compare os planos ou leia o que uma assinatura de DevOps gerenciado substitui.