Conceito e mecanismo
Diagnosticar exige comparar observações com o comportamento esperado do sistema. Constrói hipóteses que possam ser apoiadas ou contrariadas por evidência. Uma release próxima do início é uma pista, não uma prova; uma falha semelhante à do mês anterior também não garante a mesma causa. Regista testes e resultados para evitar repetir caminhos já excluídos. Escolhe verificações que distingam hipóteses com pouco risco. Uma consulta pode ser preferível a uma alteração se fornecer a mesma informação. Quando a investigação exige mudança, explicita responsável, estado esperado, critério de interrupção e forma de recuperação. Runbooks precisam de corresponder à versão, dependências e condições atuais, não apenas ao nome do alerta.
Aplicação guiada
A redução de impacto não precisa de esperar pela análise causal completa. Num exemplo fictício, limitar uma funcionalidade não essencial pode recuperar capacidade para operações prioritárias, desde que o modo degradado seja autorizado e o efeito medido. Um rollback pode ajudar, mas exige verificar compatibilidade de dados e mudanças dependentes; reiniciar todos os nós pode destruir disponibilidade e evidência. Preserva informação relevante quando viável e evita recolhas pesadas sem avaliar o custo. Depois da ação, compara o resultado com o esperado, incluindo operações dos utilizadores, filas e dados. Se a hipótese falhar, atualiza o registo e muda de direção. Um comando concluído com sucesso demonstra execução, não recuperação funcional nem eliminação da causa.
Rollback concluído com erros persistentes exige rever a hipótese e a mitigação.
Armadilhas comuns
Correlação como causa; reinício automático; runbook fora de contexto; execução como recuperação.
Tópicos relacionados: Triagem e impacto · Coordenação e responsabilidades · Comunicação e evidência
Liga cada ação a uma hipótese, efeito esperado e verificação.
Referência: Hypothesis-driven troubleshooting · Incident management practices 2026-09; scoped Google SRE, PagerDuty and Atlassian examples