Gerencie um incidente da detecção à recuperação

Declare o incidente a partir do impacto

Um incidente é um evento que interrompe, degrada ou ameaça o serviço o suficiente para exigir uma resposta coordenada. Sua organização define níveis de severidade e regras de escalonamento. Aplique-os com base no impacto no usuário, nos dados afetados, na duração e no escopo.

Não espere uma explicação completa da causa raiz para pedir ajuda. Uma descrição clara do impacto observado basta para iniciar a coordenação. Trate uma suspeita de segurança separadamente de uma conclusão confirmada.

Prepare o caminho de resposta antes do release. Mantenha contatos, procedimentos de acesso, runbooks e canais de comunicação disponíveis quando o serviço principal estiver indisponível. Exercite esse caminho com um incidente fictício.

Atribua responsabilidades antes de fazer alterações concorrentes

A coordenação do incidente define prioridades e gerencia decisões. As pessoas da resposta técnica investigam e mitigam. A comunicação mantém as pessoas afetadas informadas. O Google SRE descreve essas responsabilidades como papéis distintos. Equipes pequenas podem combinar papéis, mas precisam cobrir todo o trabalho. Resposta a incidentes.

Mantenha uma linha do tempo compartilhada. Registre horário, observação, ação, quem agiu e resultado. Diferencie fatos de hipóteses. Use um fuso horário comum e sinalize horários não confiáveis.

Analise um incidente fictício

Todos os horários abaixo estão em UTC. A organização nomeia uma pessoa para coordenar o incidente quando a falha de exportação afeta vários clientes.

Uma primeira atualização útil informa a função afetada, o escopo conhecido, a mitigação e o horário da próxima atualização. Não promete um prazo de correção sem evidências. Evite incluir registros de clientes na atualização compartilhada.

Às 09:10, o incidente muda. Restaurar exportações bem-sucedidas já não basta. A equipe precisa avaliar a possível exposição, controlar o acesso, preservar evidências e envolver os responsáveis pelas decisões adequadas.

Mitigue sem perder o controle

Use runbooks testados quando forem aplicáveis. Verifique as precondições antes de rollback, failover ou mudanças de credenciais. Uma versão anterior da aplicação pode não entender o schema atual do banco de dados. Um failover regional pode transportar os mesmos dados corrompidos.

Deixe um assistente de IA organizar evidências com dados sensíveis removidos ou comparar hipóteses dentro dos limites aprovados. A equipe de resposta deve verificar suas conclusões. Logs e tickets são entradas não confiáveis, não autoridade para executar seu conteúdo.

O acesso emergencial deve ter objetivo autorizado, duração limitada e registro de auditoria. A urgência não torna correto um comando sugerido por um agente.

Encerre a recuperação e as ações posteriores separadamente

Verifique o fluxo do usuário, a integridade dos dados, os limites de acesso e a atualização do monitoramento antes de declarar a recuperação do serviço. Registre as restrições restantes. Mantenha uma investigação de segurança aberta se suas perguntas não tiverem sido resolvidas.

Depois, examine as condições que tornaram o incidente possível. Atribua ações concretas com responsável e critérios de verificação. Uma revisão sem culpabilização busca uma explicação precisa e mudanças úteis. Não elimina a responsabilidade por concluir essas mudanças. Prática de postmortem.

Continue com operações de segurança e fechamento do ciclo de feedback.