Gerir um incidente desde a deteção até à recuperação

Declare o incidente com base no impacto

Um incidente é um evento que interrompe, degrada ou ameaça o serviço o suficiente para exigir uma resposta coordenada. A organização define níveis de gravidade e regras de escalamento. Use o impacto nos utilizadores, os dados afetados, a duração e o âmbito para os aplicar.

Não espere por uma explicação completa da causa principal antes de 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 a via de resposta antes do lançamento. Mantenha contactos, procedimentos de acesso, runbooks e canais de comunicação disponíveis quando o serviço principal estiver indisponível. Exercite essa via com um incidente fictício.

Atribua responsabilidades antes de fazer alterações concorrentes

A coordenação do incidente estabelece prioridades e gere decisões. Os responsáveis pela resposta técnica investigam e mitigam. A comunicação mantém as pessoas afetadas informadas. O Google SRE descreve estas responsabilidades como funções distintas. Equipas pequenas podem combinar funções, mas têm de assegurar todo o trabalho. Resposta a incidentes.

Mantenha uma cronologia partilhada. Registe a hora, a observação, a ação, quem a executou e o resultado. Distinga factos de hipóteses. Use um fuso horário comum e assinale registos temporais pouco fiáveis.

Trabalhe um incidente fictício

Todas as horas abaixo estão em UTC. A organização nomeia um coordenador do incidente quando a falha do export afeta vários clientes.

Uma primeira atualização útil indica a funcionalidade afetada, o âmbito conhecido, a mitigação e a hora da próxima atualização. Não promete um prazo de correção sem evidências. Evite incluir registos de clientes na atualização partilhada.

Às 09:10, o incidente muda. Repor exports bem-sucedidos já não basta. A equipa precisa de avaliar uma possível divulgação, controlar o acesso, preservar evidências e envolver os responsáveis adequados pelas decisões.

Mitigue sem perder o controlo

Use runbooks testados onde forem aplicáveis. Verifique as pré-condições antes de um rollback, failover ou alteração de credenciais. Uma versão anterior da aplicação pode não compreender o esquema atual da base de dados. Um failover entre regiões pode transportar os mesmos dados corrompidos.

Permita que um assistente de IA organize evidências sem informação sensível ou compare hipóteses dentro dos limites aprovados. Os responsáveis pela resposta têm de verificar as conclusões. Logs e tickets são entradas não fiáveis, não autoridade para executar o seu conteúdo.

O acesso de emergência deve ter uma finalidade autorizada, duração limitada e um registo de auditoria. A urgência não torna correto um comando sugerido por um agente.

Encerre a recuperação e o trabalho posterior separadamente

Verifique o fluxo do utilizador, a integridade dos dados, os limites de acesso e a atualidade da monitorização antes de declarar a recuperação do serviço. Registe quaisquer restrições restantes. Mantenha uma investigação de segurança aberta se as suas perguntas continuarem sem resposta.

Depois, examine as condições que permitiram o incidente. Atribua trabalho posterior concreto, com responsável e critérios de verificação. Uma revisão sem culpabilização procura uma explicação rigorosa e alterações úteis. Não elimina a responsabilidade de concluir essas alterações. Prática de postmortem.

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