Revisão de Casos de Suporte
Use esta habilidade ao investigar um incidente e precisar revisar casos de suporte da AWS — seja o caso atual associado ao incidente ou casos históricos que possam conter contexto relevante, sintomas semelhantes ou etapas de remediação comprovadas.
Quando Usar Esta Habilidade
- Um incidente ativo compartilha sintomas com problemas resolvidos anteriormente.
- Você precisa verificar se um caso de suporte semelhante foi aberto nos últimos 24 meses.
- Você deseja correlacionar o incidente atual com eventos conhecidos de serviços AWS.
- Você precisa recuperar comunicações e detalhes de resolução de um caso anterior.
- Você quer identificar padrões recorrentes em vários casos de suporte.
Pré-requisitos
- A conta AWS deve ter um plano Business Support+, Enterprise Support ou Unified Operations (necessário para a API AWS Support).
- O agente deve ter permissões para chamar
support:DescribeCasesesupport:DescribeCommunicationsna conta de destino. - Os dados dos casos de suporte estão disponíveis por 24 meses após a criação. Casos com mais de 24 meses não podem ser recuperados via API.
Etapa 1: Identificar o Contexto do Incidente Atual
Antes de pesquisar casos de suporte, colete detalhes importantes do incidente atual:
- Serviços AWS afetados (por exemplo, EC2, RDS, Lambda, ELB).
- Mensagens de erro ou códigos de erro observados em logs ou alarmes.
- Período de tempo do incidente (hora de início, duração).
- Recursos afetados (IDs de instância, ARNs, nomes de endpoints).
- Sintomas (picos de latência, erros 5xx, timeouts de conexão, throttling).
Use esses detalhes como critérios de pesquisa ao filtrar casos de suporte.
Etapa 2: Pesquisar Casos de Suporte Relacionados
Use a API AWS Support para recuperar casos que possam ser relevantes.
Recuperar todos os casos recentes (abertos e resolvidos)
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"
Filtrar por IDs de caso específicos (se conhecidos)
aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communications
Principais estratégias de filtragem
| Estratégia | Como Aplicar |
|---|---|
| Por janela de tempo | Use --after-time e --before-time para limitar os casos ao período relevante (ex.: últimos 30 dias ou em torno de uma data de incidente anterior), pois casos recentes tendem a refletir o estado atual da infraestrutura. |
| Por serviço | Revise o campo serviceCode nos casos retornados para corresponder ao serviço afetado (ex.: amazon-elastic-compute-cloud, amazon-rds), porque o mesmo serviço frequentemente exibe padrões de falha recorrentes. |
| Por severidade | Verifique o campo severityCode — concentre-se em casos urgent e critical para incidentes graves, pois casos de maior severidade tendem a ter análises de causa raiz mais detalhadas do Suporte AWS. |
| Por status | Use --include-resolved-cases para incluir casos fechados, pois casos resolvidos contêm a causa raiz e as etapas de remediação que são mais valiosas para correlação com o incidente atual. |
| Por palavras-chave no assunto | Examine o campo subject dos casos retornados em busca de palavras-chave que correspondam aos sintomas do incidente atual, pois sintomas semelhantes geralmente compartilham causas subjacentes. |
Etapa 3: Revisar Comunicações do Caso
A resposta do describe-cases com includeCommunications: true retorna as comunicações mais recentes de cada caso no campo recentCommunications (até 5 mensagens). Como a análise de causa raiz e as etapas de resolução geralmente estão nas mensagens finais de um caso resolvido, isso geralmente é suficiente.
Se o campo recentCommunications incluir um nextToken, o caso possui mensagens antigas adicionais. Pagine usando describe-communications apenas se as mensagens recentes não contiverem uma causa raiz ou resolução clara — por exemplo, se as últimas mensagens forem perguntas de acompanhamento em vez de uma resposta final.
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"
Ao revisar as comunicações, procure por:
- Declarações de causa raiz — Os engenheiros do Suporte AWS geralmente resumem a causa raiz em sua resposta final.
- Etapas de remediação — Ações específicas tomadas para resolver o problema (ex.: "aumentou max_connections", "aplicou regra de grupo de segurança", "escalou o tipo de instância").
- Recomendações de configuração — Práticas recomendadas ou sugestões de ajuste fornecidas pela AWS.
- Notas de escalação — Se o caso foi escalado, verifique se há análises técnicas mais aprofundadas de equipes especializadas.
Etapa 4: Correlacionar Descobertas com o Incidente Atual
Após revisar os casos relevantes, correlacione as descobertas:
Lista de verificação de correspondência de padrões
- Os casos anteriores compartilham o mesmo serviço afetado e tipo de recurso?
- As mensagens ou códigos de erro são idênticos ou semelhantes?
- Os incidentes anteriores ocorreram em horário ou dia da semana semelhante (indicando padrões de carga)?
- A causa raiz foi um problema de configuração que ainda pode estar presente?
- A resolução foi uma solução alternativa temporária que expirou ou foi revertida?
- A AWS identificou um problema no lado do serviço que pode estar recorrendo?
Pontuação de relevância
Classifique cada caso histórico quanto à relevância para o incidente atual:
| Pontuação | Critério |
|---|---|
| Alta | Mesmo serviço, mesmo erro, mesmo tipo de recurso, período de tempo semelhante |
| Média | Mesmo serviço, erro diferente, mas sintomas relacionados |
| Baixa | Serviço diferente, mas padrão arquitetural ou modo de falha semelhante |
Etapa 5: Resumir Descobertas
Forneça um resumo estruturado incluindo:
- Número de casos relacionados encontrados — Quantos casos anteriores corresponderam aos critérios de pesquisa.
- Caso(s) mais relevante(s) — ID do caso, assunto, status e data de criação das principais correspondências.
- Causas raiz históricas — O que causou problemas semelhantes no passado.
- Resoluções anteriores — Quais etapas de remediação foram aplicadas e se foram correções permanentes ou soluções alternativas temporárias.
- Recomendações — Com base em padrões históricos, sugira caminhos de investigação ou etapas de remediação para o incidente atual.
- Alerta de padrão recorrente — Se o mesmo problema ocorreu várias vezes, sinalize-o como um problema recorrente que requer uma correção definitiva ou uma mudança arquitetural.
Árvore de Decisão: Estratégia de Pesquisa de Casos
Existe um ID de caso conhecido associado ao incidente atual?
├── SIM → Recupere esse caso específico e suas comunicações (Etapa 2, filtrar por ID do caso)
└── NÃO → Continue abaixo
O serviço AWS afetado é conhecido?
├── SIM → Pesquise casos nos últimos 90 dias para esse serviço e depois expanda para 12 meses, se necessário
└── NÃO → Pesquise todos os casos nos últimos 30 dias e filtre por palavras-chave de erro
Foram encontrados casos históricos relevantes?
├── SIM → Revise as comunicações (Etapa 3), correlacione as descobertas (Etapa 4), resuma (Etapa 5)
└── NÃO → Amplie os critérios de pesquisa:
- Expanda a janela de tempo
- Pesquise por serviços relacionados (ex.: se o ELB foi afetado, verifique também casos do EC2 e do Target Group)
- Pesquise por código de erro ou palavras-chave de sintoma nos assuntos dos casos
Dicas para uma Revisão Eficaz de Casos
- Comece restrito, depois amplie: Inicie com filtros específicos (serviço + janela de tempo) e expanda apenas se nenhum caso relevante for encontrado.
- Verifique casos resolvidos: As informações mais valiosas geralmente vêm de casos resolvidos, onde a causa raiz e a correção estão documentadas.
- Observe padrões de severidade dos casos: Se casos anteriores para o mesmo problema foram abertos com severidade
critical, o incidente atual pode justificar urgência semelhante. - Faça referência cruzada com implantações: Se um caso anterior foi causado por uma implantação, verifique se uma implantação semelhante ocorreu antes do incidente atual.