Fluxograma de resposta a incidentes: do primeiro alerta ao postmortem

Às três da manhã, ninguém lê uma política de incidentes de dez páginas. Quem está de plantão precisa saber quatro coisas rapidamente: isso é real, é um incidente, quem mais precisa saber e o que fazer primeiro. Um fluxograma de uma página responde a essas perguntas na ordem em que elas surgem, e é a parte da política que as pessoas realmente seguem.

Este artigo monta um fluxograma de resposta a incidentes para uma equipe de engenharia que opera um serviço em produção: triagem, critérios para declarar um incidente, severidade e papéis, mitigação e o postmortem que fecha o ciclo. No final, há dicas de desenho para que o fluxograma continue útil sob pressão.

O que o fluxograma precisa decidir

Um processo de incidentes é uma série de decisões com algumas atividades longas entre elas. As decisões vão no diagrama, escritas como perguntas com respostas rotuladas:

• O alerta é real e acionável? Se não for, o problema é o alerta.
• É um incidente? Se não for, é trabalho normal com um ticket.
• Qual a gravidade? A severidade decide quem é acionado e quem é avisado.
• O serviço foi restabelecido? Se não, tente a próxima mitigação ou escale.

Todo o resto, como reverter um deploy ou fazer failover de um banco de dados, fica em runbooks com links a partir do diagrama.

Quando declarar um incidente

Declarar é o passo em que as equipes hesitam, e essa hesitação custa caro. O capítulo Managing Incidents do livro de SRE do Google defende declarar cedo: é melhor declarar, encontrar uma correção simples e encerrar o incidente do que iniciar o processo horas depois do começo de um problema crescente. A equipe desse capítulo declara um incidente quando qualquer uma destas condições é verdadeira:

1. Uma segunda equipe é necessária para resolver o problema.
2. A falha é visível para os clientes.
3. O problema continua sem solução depois de uma hora de análise concentrada.

Coloque seus próprios critérios no diagrama, ao lado da decisão. Critérios claros eliminam o custo social de declarar.

Papéis

O mesmo capítulo descreve uma estrutura baseada no Incident Command System. Mesmo uma equipe pequena ganha ao nomear os papéis, porque a falha mais comum é uma só pessoa assumir todos eles:

O comandante do incidente também mantém um documento vivo do incidente e faz a passagem de forma explícita no fim do turno: o comandante que sai anuncia a passagem e espera a confirmação.

Habilidades de gestão de incidentes enferrujam quando não são usadas. O mesmo capítulo sugere aplicar o modelo a mudanças operacionais que envolvem várias equipes ou fusos horários e encenar incidentes passados, para que o processo já seja familiar antes do próximo incidente real. Percorrer o fluxograma com uma pessoa nova no plantão usando um incidente antigo é um jeito barato de começar.

Níveis de severidade

As definições de severidade variam de empresa para empresa, então trate estas como exemplo e escreva as suas no diagrama:

O fluxograma, passo a passo

1. Reconhecer e triar. Quando o alerta disparar, reconheça-o para que o acionamento pare de escalar e depois avalie o alcance e o impacto.
2. Real e acionável? Um alerta falso ou não acionável é ajustado ou removido e depois encerrado.
3. É um incidente? Aplique os critérios. Se não for, trate como trabalho normal com um ticket.
4. Declarar. Defina o comandante do incidente, abra um canal e o documento do incidente.
5. Severidade. Em SEV-1 e SEV-2, um responsável pela comunicação publica na página de status e envia atualizações regulares.
6. Mitigar primeiro. Faça rollback, failover, desligue a feature flag ou descarte carga. A primeira prioridade no livro de SRE é estancar o sangramento, restaurar o serviço e preservar as evidências; a causa raiz vem depois.
7. Restabelecido? Se não, tente a próxima mitigação ou escale, e repita o loop.
8. Resolver. Confirme com métricas, continue observando e devolva o sistema à operação normal.
9. Postmortem e ações. Escreva um postmortem sem culpa, revise-o e encerre o incidente quando as ações estiverem registradas.

Como ler:

• Sim vai para a direita, Não vai para baixo. Todas as decisões usam a mesma convenção, então o caminho principal avança para a direita e as saídas antecipadas descem.
• À esquerda, a primeira resposta. O alerta é reconhecido e triado. Alertas que não são reais nem acionáveis, e eventos que não são incidentes, terminam em Done.
• Terceira coluna, o incidente. Ele é declarado, tem a severidade verificada e é mitigado. SEV-1 e SEV-2 acrescentam um responsável pela comunicação à direita.
• O loop. "Service restored?" leva você de volta à mitigação até que a resposta seja sim.
• Coluna da direita, o encerramento. Resolva, escreva o postmortem sem culpa e encerre quando as ações estiverem registradas.
• As notas trazem os critérios de declaração e os níveis de severidade, para que ninguém precise abrir outro documento.

O postmortem fecha o ciclo

O capítulo Postmortem Culture do livro de SRE lista gatilhos comuns, como indisponibilidade ou degradação visível para os usuários acima de um limite e perda de dados de qualquer tipo. Um postmortem é sem culpa quando procura causas contribuintes em sistemas e processos sem culpar pessoas; caso contrário, as pessoas param de relatar problemas. Desenhe o postmortem no diagrama como um documento com responsável e prazo, e não marque o incidente como encerrado até que as ações estejam registradas.

Incidentes de segurança precisam de mais do que este diagrama: preservação de evidências, etapas legais e regulatórias e, muitas vezes, uma equipe separada. O NIST SP 800-61 Rev. 3, publicado em abril de 2025, é a referência usual. Ligue um ramo de segurança a esse processo em vez de improvisar um.

Dicas de desenho para fluxogramas usados sob pressão

• Um início, fins claros. Todo caminho deve terminar em algum lugar, mesmo que seja "Done".
• Decisões como perguntas de sim ou não, com as duas saídas rotuladas, e Sim e Não saindo sempre pelos mesmos lados.
• Deixe os loops explícitos. "Tente a próxima mitigação" é um loop, não uma nota de rodapé.
• No máximo quinze formas. Os detalhes ficam em runbooks com links a partir das etapas.
• Mostre onde a responsabilidade muda. Para uma versão com raias por papel, comece pelo modelo de fluxograma multifuncional.
• Deixe onde o plantão olha. Coloque um link ou incorpore o diagrama ao vivo no runbook em vez de colar uma captura de tela.

Se o seu processo envolve muitas equipes e passagens formais, um diagrama BPMN pode modelá-lo com mais precisão; para o plantão, um fluxograma é mais fácil de seguir.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Do pack Fluxograma, adicione um Início / Fim para o começo e para cada fim, um Processo para cada etapa e uma Decisão para cada pergunta.
3. Adicione um Documento para o postmortem.
4. Conecte as formas. A forma Decisão marca Y no canto direito e N no canto inferior, então desenhe Sim para a direita e Não para baixo, rotule as duas saídas e leve a saída "não restabelecido" de volta à mitigação.
5. Adicione nós Nota do pack Básico com seus critérios de declaração e níveis de severidade.

O exemplo usa 15 nós de diagrama e fica dentro do plano Free. A página do criador de fluxogramas mostra as outras formas e o layout com raias.

Perguntas frequentes

Quem deve ser responsável pelo fluxograma de resposta a incidentes? A equipe que organiza a escala de plantão. Revise-o depois de cada incidente em que alguém não soube o que fazer em seguida.

Todo alerta deve virar um incidente? Não. A maioria dos alertas deve ser tratada como trabalho normal. Declare quando seus critérios forem atendidos e, na dúvida, declare cedo.

Preciso de um comandante do incidente em incidentes pequenos? Alguém precisa manter a visão geral. Em um incidente pequeno, quem está de plantão é o comandante, e dizer isso em voz alta evita que duas pessoas corrijam a mesma coisa de jeitos diferentes.

Quando o postmortem deve ser escrito? Logo, enquanto os detalhes estão frescos. Defina um prazo que sua equipe consiga cumprir, coloque-o no diagrama e acompanhe as ações.

O fluxograma deve incluir incidentes de segurança? Adicione um ramo que os encaminhe para o seu processo de incidentes de segurança. Esse processo tem etapas diferentes, como a preservação de evidências e a revisão jurídica.

Comece grátis — um assento, sem cartão de crédito.