Método de Diagnóstico Estruturado
A Abordagem Sistemática
Em computação, e especialmente na nuvem, o troubleshooting não deve ser feito por "tentativa e erro" aleatória. Um método estruturado vai economizar seu tempo e torná-lo mais eficiente.
┌─────────────────────────────────────────────────────────────┐
│ MÉTODO DE DIAGNÓSTICO EM 5 ETAPAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. SINTOMA │
│ └── O que exatamente não está funcionando? │
│ Seja preciso! "Não funciona" não é um │
│ sintoma válido. │
│ │
│ 2. HIPÓTESES │
│ └── Quais são as causas possíveis? │
│ Liste por probabilidade. │
│ │
│ 3. TESTES │
│ └── Como verificar cada hipótese? │
│ Um teste de cada vez, metodicamente. │
│ │
│ 4. CORREÇÃO │
│ └── Qual ação resolve o problema? │
│ Aplique e valide. │
│ │
│ 5. DOCUMENTAÇÃO │
│ └── Anote a solução para referência futura. │
│ Atualize o runbook. │
│ │
└─────────────────────────────────────────────────────────────┘
Etapa 1: Definir o Sintoma
Sintoma Ruim vs Bom
❌ SINTOMAS RUINS (muito vagos):
• "O servidor não funciona"
• "Está quebrado"
• "Tenho um erro"
• "Funcionava antes"
✅ BONS SINTOMAS (precisos):
• "Timeout de SSH após 30 segundos para o IP 52.1.2.3"
• "Erro 502 Bad Gateway em http://example.com"
• "Instância i-xxx muda para terminated após 10 segundos"
• "Página web retorna erro 500 desde 14h30"
Perguntas a Fazer
┌─────────────────────────────────────────────────────────────┐
│ PERGUNTAS DE ESCLARECIMENTO │
├─────────────────────────────────────────────────────────────┤
│ │
│ O QUÊ? │
│ • Qual é a mensagem de erro exata? │
│ • Qual funcionalidade está afetada? │
│ • Qual serviço/instância está envolvido? │
│ │
│ QUANDO? │
│ • Quando o problema começou? │
│ • O problema é constante ou intermitente? │
│ • Existem padrões (horários, dias)? │
│ │
│ ONDE? │
│ • Qual região/AZ? │
│ • Qual instância/recurso? │
│ • De onde o problema é observado? │
│ │
│ QUEM? │
│ • Todos os usuários ou apenas alguns? │
│ • De certas redes/IPs? │
│ │
│ MUDANÇA? │
│ • O que mudou recentemente? │
│ • Deploy? Configuração? AWS? │
│ │
└─────────────────────────────────────────────────────────────┘
Etapa 2: Formular Hipóteses
Categorias de Problemas EC2
┌─────────────────────────────────────────────────────────────┐
│ CATEGORIAS DE PROBLEMAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🌐 REDE │
│ ├── Security Group mal configurado │
│ ├── NACL bloqueando │
│ ├── Route Table incorreta │
│ ├── Internet Gateway ausente │
│ └── Sem IP pública │
│ │
│ 🔐 SEGURANÇA / AUTH │
│ ├── Chave SSH errada │
│ ├── Usuário incorreto │
│ ├── Permissões do arquivo .pem │
│ └── IAM (para chamadas de API) │
│ │
│ 💻 INSTÂNCIA │
│ ├── Instância não está running │
│ ├── Status check failed │
│ ├── Serviço não iniciado (Apache, SSH) │
│ └── Disco cheio │
│ │
│ 📦 APLICAÇÃO │
│ ├── Aplicação crashou │
│ ├── Configuração incorreta │
│ ├── Dependência ausente │
│ └── Porta incorreta │
│ │
│ ☁️ AWS │
│ ├── Falha regional │
│ ├── Serviço degradado │
│ └── Manutenção │
│ │
└─────────────────────────────────────────────────────────────┘
Priorizar as Hipóteses
Regra de ouro: Do mais simples ao mais complexo
Do mais provável ao menos provável
Exemplo para "SSH timeout":
ALTA PROBABILIDADE (verificar primeiro)
1. Security Group - porta 22 fechada
2. Sem IP público
3. Instância não está running
PROBABILIDADE MÉDIA
4. NACL bloqueando
5. Route table sem rota para IGW
6. Firewall na instância
BAIXA PROBABILIDADE
7. Falha regional da AWS
8. Bug no cliente SSH
Etapa 3: Testar as Hipóteses
Testes para Problemas de Rede
# 1. Verificar o estado da instância
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].State.Name'
# 2. Verificar o IP público
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].PublicIpAddress'
# 3. Verificar os Security Groups
aws ec2 describe-security-groups --group-ids sg-xxx
# 4. Testar conectividade de rede (da sua máquina)
ping IP_PUBLIQUE # ICMP (se permitido)
telnet IP_PUBLIQUE 22 # Teste porta SSH
nc -zv IP_PUBLIQUE 22 # Alternativa ao telnet
# 5. Verificar a route table do subnet
aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-xxx"
Testes para Problemas de Instância
# 1. Verificar os status checks
aws ec2 describe-instance-status --instance-ids i-xxx
# 2. Recuperar os logs do sistema (se configurado)
aws ec2 get-console-output --instance-id i-xxx
# 3. Verificar as métricas do CloudWatch
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-xxx \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T01:00:00Z \
--period 300 \
--statistics Average
A partir da Instância (se acessível)
# Verificar os serviços
systemctl status sshd
systemctl status httpd
# Verificar as portas abertas
netstat -tlnp
ss -tlnp
# Verificar espaço em disco
df -h
# Verificar memória
free -m
# Verificar logs
tail -100 /var/log/messages
tail -100 /var/log/secure
journalctl -xe
Etapa 4: Aplicar a Correção
Regras para Correções
┌─────────────────────────────────────────────────────────────┐
│ REGRAS PARA APLICAR UMA CORREÇÃO │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. UMA MUDANÇA POR VEZ │
│ └── Não mude 5 coisas ao mesmo tempo! │
│ └── Senão você não saberá o que resolveu │
│ │
│ 2. DOCUMENTAR ANTES DE MUDAR │
│ └── Anote o estado atual │
│ └── Poder voltar atrás │
│ │
│ 3. TESTAR APÓS CADA MUDANÇA │
│ └── Verifique se o problema foi resolvido │
│ └── Verifique se não criou novos problemas │
│ │
│ 4. VALIDAR COMPLETAMENTE │
│ └── O teste rápido OK não é suficiente │
│ └── Teste todos os casos de uso afetados │
│ │
└─────────────────────────────────────────────────────────────┘
Exemplo de Correção Documentada
PROBLEMA: Timeout de SSH para instância i-0123456789
DIAGNÓSTICO:
- Instância: running ✓
- IP público: 52.1.2.3 ✓
- Security Group: sg-abc123
→ Porta 22: AUSENTE ❌
CORREÇÃO APLICADA:
aws ec2 authorize-security-group-ingress \
--group-id sg-abc123 \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
VALIDAÇÃO:
ssh -i minha-chave.pem ec2-user@52.1.2.3
→ Conexão bem-sucedida ✓
DATA: 2024-12-18 14:30
TÉCNICO: Haythem
Etapa 5: Documentar
Template de Documentação
# Incidente: [Título curto]
## Data e Duração
- Início: YYYY-MM-DD HH:MM
- Resolução: YYYY-MM-DD HH:MM
- Duração total: X horas
## Sintoma
[Descrição precisa do problema observado]
## Impacto
- Usuários afetados: X
- Serviços impactados: [lista]
- Nível de severidade: Crítico/Maior/Minor
## Causa Raiz
[Explicação da causa fundamental]
## Cronologia
- HH:MM - Detecção do problema
- HH:MM - Início do diagnóstico
- HH:MM - Causa identificada
- HH:MM - Correção aplicada
- HH:MM - Validação e encerramento
## Solução Aplicada
[Descrição da correção]
## Ações Preventivas
- [ ] Ação 1 para evitar recorrência
- [ ] Ação 2
- [ ] Atualização do runbook
## Lições Aprendidas
[O que foi aprendido com este incidente]
Exercício Prático
Cenário
Contexto:
Você lançou uma instância EC2 há 5 minutos.
A instância está em estado "running".
Você tenta se conectar via SSH.
Resultado:
$ ssh -i minha-chave.pem ec2-user@52.1.2.3
ssh: connect to host 52.1.2.3 port 22: Connection timed out
Aplique o método de diagnóstico!
Resposta Guiada
ETAPA 1: SINTOMA
"Timeout de SSH após 30 segundos para 52.1.2.3 porta 22
a partir do meu computador (IP: 203.0.113.50)"
ETAPA 2: HIPÓTESES (por probabilidade)
1. Security Group - porta 22 não aberta ou IP não autorizado
2. Sem rota para Internet Gateway
3. NACL bloqueando a porta 22
4. Instância ainda não totalmente inicializada
ETAPA 3: TESTES
Teste 1: Security Group
→ aws ec2 describe-security-groups --group-ids sg-xxx
→ Resultado: Porta 22 aberta apenas para 10.0.0.0/8
→ Meu IP 203.0.113.50 não está autorizado!
ETAPA 4: CORREÇÃO
aws ec2 authorize-security-group-ingress \
--group-id sg-xxx \
--protocol tcp \
--port 22 \
--cidr 203.0.113.50/32
VALIDAÇÃO:
ssh -i minha-chave.pem ec2-user@52.1.2.3
→ Conexão bem-sucedida!
ETAPA 5: DOCUMENTAÇÃO
[Preencher o template acima]
Resumo
| Etapa | Ação | Duração Típica |
|---|---|---|
| 1. Sintoma | Definir precisamente | 2-5 min |
| 2. Hipóteses | Listar por probabilidade | 5-10 min |
| 3. Testes | Verificar metodicamente | Variável |
| 4. Correção | Uma mudança por vez | Variável |
| 5. Documentação | Sempre documentar | 10-15 min |
Quiz de Validação
- Por que é importante testar uma hipótese por vez?
- Qual a diferença entre um sintoma vago e um preciso?
- Por onde começar: causas prováveis ou improváveis?
- Por que documentar até mesmo pequenos incidentes?
- O que fazer se a primeira correção não funcionar?
Próxima seção: Lab: Cenários de Falha