Investigar Problema

Aprenda a conduzir uma investigacao de causa raiz de forma estruturada e eficiente.

Detalhe do Problema - Defender360

PRB-0044Erro Conhecido

Falha de autenticacao VPN pos-atualizacao

Alta Prioridade

Aberto ha 7 dias

15 tickets relacionados

Responsavel: Carlos Silva

Historico da Investigacao

Problema registrado25/01 09:15

Criado automaticamente a partir de tickets relacionados

por Sistema

Investigacao iniciada25/01 10:30

Analise de logs do servidor VPN

por Carlos Silva

Causa raiz identificada26/01 14:00

Conflito de certificados apos atualizacao

por Carlos Silva

Workaround documentado26/01 16:45

Reinstalar certificado raiz resolve temporariamente

por Ana Costa

Tickets Relacionados

TKT-1234VPN nao conecta apos atualizacao

Pendente

TKT-1238Erro de certificado na conexao VPN

Pendente

TKT-1241Falha de autenticacao VPN - Departamento Financeiro

Aberto

Workaround Documentado

Solucao Temporaria Disponivel

Reinstalar o certificado raiz do servidor VPN no dispositivo do usuario resolve o problema temporariamente. Instruções detalhadas disponíveis no KB-0892.

Ver artigo KB-0892 →

Visao Geral da Investigacao

A investigacao de problemas segue um fluxo estruturado para garantir que a causa raiz seja identificada e a solucao seja duradoura.

Fluxo de Investigacao


Deteccao ──► Registro ──► Categorizacao ──► Investigacao ──► Diagnostico
                                                              │
                                                              ▼
                                   Fechamento ◄── Resolucao ◄── Erro Conhecido

Abrindo a Investigacao

Preparacao Inicial

Antes de iniciar a investigacao, reuna:

Informacao	Fonte	Por que
Lista de incidentes	Sistema	Entender impacto e padrao
Logs de sistema	Monitoramento	Evidencias tecnicas
Timeline de eventos	Chamados	Sequencia de ocorrencias
Configuracoes	CMDB	Estado dos sistemas
Mudancas recentes	Historico	Correlacao com alteracoes

Crie uma pasta ou workspace dedicado ao problema para organizar todas as evidencias.

Atribuindo o Problema

Verifique sua especialidade e disponibilidade
Considere a complexidade do problema
Avalie se precisa de equipe multidisciplinar
Atribua a si mesmo ou monte um time

Timeline e Atividades

Registrando Atividades

O Defender360 mantem uma timeline completa do problema:

Tipo de Atividade	Quando Registrar	Exemplo
Nota de Investigacao	Cada descoberta importante	”Logs indicam erro de memoria”
Evidencia	Ao coletar dados	Anexar screenshot, log file
Hipotese	Ao formular teoria	”Possivel vazamento de memoria”
Teste Realizado	Ao validar hipotese	”Teste de stress confirmou leak”
Conclusao	Ao confirmar causa	”Causa: bug na versao 2.3.1”

Formatando Notas de Investigacao

Use um formato consistente:


## [DATA] - Analise de Logs
 
### O que foi feito
Revisao dos logs do servidor X entre 14:00-16:00
 
### Descobertas
- Erro "OutOfMemoryException" as 14:23
- Processo Y consumindo 98% da memoria
- Ultima reinicializacao: 45 dias atras
 
### Proximos passos
- Coletar heap dump
- Verificar versao do processo Y
 
### Anexos
- log_servidor_x.txt
- screenshot_htop.png

Notas bem documentadas facilitam handover para outros analistas e servem como historico.

Metodologias de Analise

Tecnica dos 5 Porques

Pergunte “Por que?” repetidamente ate chegar na causa raiz:

Nivel	Pergunta	Resposta
1	Por que o email parou?	Servidor ficou sem espaco
2	Por que ficou sem espaco?	Logs cresceram demais
3	Por que logs cresceram?	Rotacao nao funcionou
4	Por que rotacao falhou?	Script tinha erro
5	Por que script tinha erro?	Nao foi testado apos mudanca
Causa Raiz		Falta de teste em mudancas

Diagrama de Ishikawa (Espinha de Peixe)

Analise categorias de causas potenciais:


                    ┌─ Pessoas ──────────┐
                    │  - Treinamento     │
                    │  - Procedimento    │
                    │                    │
        ┌───────────┤                    ├───────────┐
        │           └────────────────────┘           │
        │ Processo                        Tecnologia │
        │ - Documentacao                  - Hardware │
        │ - Aprovacao                     - Software │
        │ - Comunicacao                   - Rede     │
        │                                            │
        └──────────────────┬─────────────────────────┘
                           │
                           ▼
                    [PROBLEMA]
                           ▲
                           │
        ┌──────────────────┴─────────────────────────┐
        │ Ambiente                        Fornecedor │
        │ - Infraestrutura                - SLA      │
        │ - Energia                       - Qualidade│
        │ - Refrigeracao                  - Suporte  │
        └────────────────────────────────────────────┘

Analise de Pareto

Identifique os 20% de causas que geram 80% dos incidentes:

Liste todas as possiveis causas
Contabilize frequencia de cada uma
Ordene por frequencia decrescente
Foque nas mais frequentes primeiro

Coletando Evidencias

Tipos de Evidencia

Tipo	Exemplos	Como Coletar
Logs	Sistema, aplicacao, seguranca	Export, grep, tail
Metricas	CPU, memoria, disco, rede	Monitoramento, graficos
Configuracoes	Arquivos, parametros	CMDB, snapshots
Depoimentos	Relatos de usuarios	Entrevistas, chamados
Screenshots	Telas de erro	Captura, gravacao

Preservando Evidencias

Boas Praticas

Nao altere sistemas em producao antes de coletar evidencias

Salve logs com timestamp e origem

Faca backup de configuracoes antes de testar

Documente o estado atual antes de qualquer mudanca

Use hash para garantir integridade de arquivos criticos

Evidencias podem ser necessarias para auditorias ou questoes legais. Preserve a cadeia de custodia.

Formulando Hipoteses

Estrutura de Hipotese

Uma boa hipotese deve ser:

Caracteristica	Descricao	Exemplo
Especifica	Claramente definida	”Vazamento de memoria no modulo X”
Testavel	Pode ser validada	”Monitorar heap por 24h”
Falsificavel	Pode ser refutada	”Se memoria estavel, hipotese incorreta”
Baseada em evidencias	Suportada por dados	”Logs mostram aumento gradual”

Registrando Hipoteses

No problema, documente cada hipotese:


## Hipotese #1: Vazamento de memoria no processo Y
 
### Base
- Logs mostram OutOfMemory apos 45 dias de uptime
- Grafico de memoria mostra crescimento linear
- Processo Y e o maior consumidor
 
### Teste proposto
- Monitorar heap dump por 48h
- Comparar uso de memoria com versao anterior
- Verificar changelogs da versao atual
 
### Resultado
[Pendente / Confirmada / Descartada]

Testando Hipoteses

Planejamento do Teste

Antes de testar:

Defina criterios de sucesso/falha
Avalie riscos do teste
Prepare rollback se necessario
Comunique stakeholders se houver impacto
Documente o plano

Ambiente de Teste

Ambiente	Quando Usar	Cuidados
Producao	Ultimo recurso, baixo risco	Janela de manutencao
Staging	Testes de impacto	Dados representativos
Dev	Testes iniciais	Pode nao reproduzir
Lab	Simulacoes	Configuracao similar

Nunca teste hipoteses destrutivas em producao sem aprovacao formal e plano de rollback.

Documentando a Causa Raiz

Quando a Causa e Identificada

Atualize o status do problema para Erro Conhecido
Documente a causa raiz detalhadamente
Avalie opcoes de solucao
Crie workaround se disponivel
Planeje solucao definitiva

Formato de Documentacao


# Causa Raiz Identificada
 
## Problema
[Descricao do problema original]
 
## Sintomas Observados
- [Sintoma 1]
- [Sintoma 2]
 
## Investigacao Realizada
1. [Analise 1 - resultado]
2. [Analise 2 - resultado]
3. [Teste que confirmou causa]
 
## Causa Raiz
[Explicacao tecnica detalhada]
 
## Sistemas Afetados
- [Sistema/versao 1]
- [Sistema/versao 2]
 
## Workaround
[Passos para contornar enquanto sem solucao]
 
## Solucao Definitiva
[Plano de correcao]
 
## Prevencao Futura
[Acoes para evitar recorrencia]

Publicando Workarounds

Criando Artigo de Workaround

No problema, clique em Criar Artigo
Selecione tipo Workaround / Erro Conhecido
Preencha os campos:
- Titulo claro e buscavel
- Sintomas que o usuario vera
- Passos do workaround
- Limitacoes conhecidas
Defina audiencia (agentes, clientes, ambos)
Publique o artigo

Vinculando a Incidentes

Quando um novo incidente relacionado chegar:

Busque o Erro Conhecido
Vincule ao incidente
Aplique o workaround
Informe o cliente sobre a situacao

Configure busca automatica de Erros Conhecidos ao criar incidentes para acelerar a resolucao.

Fechando a Investigacao

Requisitos para Fechamento

Checklist de Fechamento

Causa raiz identificada e documentada

Solucao definitiva implementada ou em andamento

Workaround publicado (se aplicavel)

Incidentes relacionados atualizados

Artigo de conhecimento criado

Metricas de impacto registradas

Licoes aprendidas documentadas

Analise Pos-Resolucao

Apos resolver, documente aprendizados:

Pergunta	Resposta
O que funcionou bem?	[Listar]
O que poderia melhorar?	[Listar]
Como detectar mais cedo?	[Sugestoes]
Como prevenir recorrencia?	[Acoes]

Metricas de Investigacao

Indicadores de Performance

Metrica	Descricao	Meta Sugerida
Tempo de Deteccao	Ate identificar o problema	< 24h
Tempo de Investigacao	Ate identificar causa	< 7 dias
Tempo de Workaround	Ate ter contorno	< 48h
Tempo de Resolucao	Ate solucao definitiva	< 30 dias
Taxa de Recorrencia	Incidentes apos resolver	< 5%

Proximos Passos

Volte para a visao geral de problemas ou explore outras areas:

Gestao de Problemas

Visao geral do modulo de problemas

Base de Conhecimento

Publique solucoes e workarounds