# Gerar relatórios de incidentes
Os relatórios de incidentes permitem redigir, com maior rapidez e facilidade, um relatório sobre a investigação de um incidente. Você pode usar esse relatório para fornecer detalhes à gerência ou ajudar sua equipe a aprender com o incidente e tomar medidas para evitar tais ocorrências no futuro. A estrutura do relatório é baseada nos padrões do setor para esses tipos de relatórios e pode ser copiada em outros repositórios para retenção a longo prazo.
Quando você usa o Console de gerenciamento da AWS para criar um recurso de *grupo de investigação* nas investigações do CloudWatch, um perfil do IAM é criado para o grupo a fim de conceder a ele acesso aos recursos durante a investigação. Para gerar relatórios de incidentes das investigações do CloudWatch é necessário que permissões adicionais sejam concedidas ao grupo de investigações. A nova política gerenciada `AIOpsAssistantIncidentReportPolicy` fornece as permissões necessárias e é adicionada automaticamente aos grupos de investigações criados usando o Console de gerenciamento da AWS após 10 de outubro de 2025. Para obter mais informações, consulte [AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy).
**nota**
Se você usar o CDK ou o SDK, deverá adicionar explicitamente o perfil do grupo de investigações e especificar a política de perfil ou as permissões integradas do perfil equivalentes. Para obter detalhes sobre permissões, consulte [Segurança nas investigações do CloudWatch](Investigations-Security.md)
Esses relatórios capturam as descobertas da investigação, as causas primárias, os eventos do cronograma e as ações corretivas recomendadas em um formato estruturado que pode ser facilmente compartilhado com as partes interessadas e usado para aprendizagem organizacional.
A geração de relatórios de incidentes é incluída sem custo adicional para todos os usuários de investigações do CloudWatch e integra-se perfeitamente ao fluxo de trabalho de investigação.
**Como funcionam os relatórios de incidentes**
1. Realize uma investigação sobre o incidente.
1. Aceite pelo menos uma das hipóteses. Toda hipótese que você aceita é considerada para o relatório. A hipótese não precisa ser 100% exata.
1. Escolha **Relatório do incidente**. Durante a investigação, a IA analisou os dados coletados para a investigação e os fatos derivados. Fatos são informações precisas sobre o incidente que servem como base para a geração do relatório. A extração dos fatos pode levar alguns minutos.
1. Quando a extração dos fatos é concluída, você pode revisar os fatos disponíveis nas seguintes áreas:
1. **Visão geral do incidente**: visão geral de alto nível do incidente, incluindo sua gravidade, duração e hipótese operacional.
1. **Avaliação de impacto**: métricas e análise relacionadas ao impacto do incidente para os clientes, a função do serviço e as operações da empresa.
1. **Detecção e resposta**: métricas e análise relacionadas a como e quando o incidente foi detectado e qual foi sua resposta ao incidente.
1. **Análise da causa primária**: análise detalhada das causas subjacentes com base nas hipóteses de investigação.
1. **Mitigação e resolução**: métricas e análise relacionadas às etapas de mitigação e às medidas para resolução, junto com a medição do tempo gasto para mitigar e resolver o incidente.
1. **Aprendizagem e próximas etapas**: uma lista de ações recomendadas para consideração de sua equipe, gerada automaticamente a partir dos resultados da investigação. Essas recomendações podem incluir medidas preventivas contra incidentes semelhantes, bem como sugestões de melhorias nos processos de monitoramento e resposta.
1. Depois de analisar os fatos, escolha **Gerar relatório** para criar uma análise abrangente do incidente. Embora os fatos selecionados sirvam como pontos de referência essenciais, o relatório se baseia em todas as informações disponíveis coletadas durante a investigação. Esse processo pode levar alguns minutos.
1. Depois de gerar o relatório, você pode:
+ Usar o relatório como está:
+ Copiá-lo para editar no editor externo, se necessário
+ Salvá-lo para referência posterior
+ Aprimorar o relatório adicionando dados:
+ Escolha **Adicionar fatos** (método recomendado) para inserir mais conteúdo baseado em texto, como tíquetes de incidentes ou narrativas personalizadas. A IA analisará esse conteúdo para ampliar os fatos existentes ou inferir novos.
+ Editar os fatos diretamente (use com moderação): fatos editados manualmente podem gerar inconsistências com o cronograma da investigação. Isso deve ser usado apenas como último recurso quando **Adicionar fatos** não atingir o resultado desejado.
+ Escolha **Gerar relatório novamente** para produzir um novo relatório usando as informações atualizadas.
**Topics**
+ [Entender os fatos derivados por IA em relatórios de incidentes](Investigations-IncidentReports-ai-facts.md)
+ [Terminologia de relatórios de incidentes](Investigations-IncidentReports-terms.md)
+ [Gerar um relatório a partir de uma investigação](Investigations-IncidentReports-Generate.md)
+ [Usar a análise dos Cinco porquês em relatórios de incidentes](incident-report-5whys.md)
# Entender os fatos derivados por IA em relatórios de incidentes
Os fatos derivados por IA são a base dos relatórios sobre incidentes das investigações do CloudWatch, representando informações que o sistema de IA considera objetivamente verdadeiras ou altamente prováveis segundo uma análise abrangente do seu ambiente da AWS. Esses fatos resultam de um processo sofisticado que combina reconhecimento de padrões de machine learning com métodos de verificação sistemática, criando uma estrutura robusta para análise de incidentes que mantém o rigor operacional necessário para ambientes de produção.
Entender como os fatos derivados por IA são desenvolvidos ajuda a avaliar sua confiabilidade e a tomar decisões embasadas durante a resposta a incidentes. O processo representa uma abordagem híbrida na qual a inteligência artificial amplia a expertise humana em vez de substituí-la, garantindo que os insights gerados sejam abrangentes e confiáveis.
## O processo de desenvolvimento de fatos derivados por IA
A jornada desde os dados brutos de telemetria até os fatos acionáveis derivados por IA começa com a observação de padrões, quando a IA das investigações do CloudWatch analisa grandes quantidades de dados de telemetria da AWS usando algoritmos sofisticados de machine learning. A IA examina as métricas, os logs e os rastros do CloudWatch em várias dimensões simultaneamente, identificando padrões recorrentes e relações que podem não ser imediatamente aparentes para operadores humanos. A análise abrange padrões temporais que revelam quando os incidentes normalmente ocorrem e suas características de duração, correlações entre serviços que mostram como diferentes serviços da AWS interagem durante cenários de falha, anomalias em métricas que precedem ou acompanham os incidentes e sequências de eventos de logs que indicam modos de falha específicos.
Considere, por exemplo, como a IA pode observar que, em seu ambiente, a utilização de CPU pela instância do Amazon EC2 atinge consistentemente picos acima de 90% aproximadamente 15 minutos antes de os tempos de resposta da aplicação excederem os limites aceitáveis. Essa relação temporal, quando observada em vários incidentes, torna-se um padrão significativo, digno de uma investigação mais aprofundada. A IA não observa simplesmente a correlação; ela mede sua significância estatística e considera vários fatores de confusão que podem influenciar o padrão.
A partir desses padrões observados, a IA passa à geração de hipóteses, formulando possíveis explicações para as relações descobertas. Esse processo envolve a criação de várias hipóteses concorrentes e sua classificação por probabilidade segundo a força das evidências corroborantes. Quando a IA observa que os picos da CPU precedem a degradação do tempo de resposta, ela pode gerar várias hipóteses: exaustão de recursos devido à capacidade computacional insuficiente, vazamentos de memória causando aumento da sobrecarga da CPU ou algoritmos ineficientes acionados por padrões de entrada específicos. Cada hipótese recebe um nível de confiança preliminar com base na qualidade de sua explicação para os dados observados e no seu alinhamento com os comportamentos conhecidos do serviço da AWS.
A verificação e validação humana dessas hipóteses garantem que os insights geradas por IA atendam aos padrões operacionais antes que se tornem fatos nos relatórios de incidentes. Esse processo envolve correlacionar padrões derivados por IA com modelos estabelecidos de comportamentos do serviço da AWS, verificar sua consistência com as práticas recomendadas do setor para resposta a incidentes e validá-los por meio de comparação com dados históricos de incidentes em ambientes semelhantes. A IA precisa demonstrar que suas descobertas podem ser reproduzidas em diferentes métodos e períodos de análise, atendem aos requisitos de significância estatística para tomada de decisões operacionais, se alinham às observações empíricas do comportamento do serviço da AWS e fornecem insights acionáveis para resolução ou prevenção de incidentes.
Durante todo esse processo, a IA enfrenta vários desafios inerentes que você deve entender ao interpretar fatos derivados por IA. A distinção entre correlação e causalidade continua sendo um desafio fundamental; embora a IA possa identificar fortes correlações entre picos de tráfego de rede e ocorrência de incidentes, estabelecer a causalidade direta requer investigação adicional e expertise no domínio. Variáveis ocultas que existem fora do escopo da telemetria da AWS, como dependências de serviços de terceiros ou problemas de provedores de rede externos, podem influenciar incidentes sem serem capturadas na análise da IA. A qualidade dos fatos derivados por IA depende inteiramente da integridade e precisão dos dados subjacentes do CloudWatch, tornando essencial uma cobertura abrangente do monitoramento para obtenção de insights confiáveis.
Os padrões de incidentes inéditos apresentam outro desafio, pois não estão incluídos nos dados de treinamento de IA, e as IAs geralmente têm dificuldade para interpretar modos de falha desconhecidos. Essa limitação ressalta a importância da expertise humana para interpretar fatos derivados por IA e complementá-los com conhecimento do domínio e compreensão contextual.
## Aplicação de fatos derivados por IA à resposta a incidentes
A IA é excelente na identificação de padrões em grandes conjuntos de dados cuja análise manual por humanos seria impraticável, fornecendo insights que podem acelerar significativamente o diagnóstico e a resolução de incidentes. A IA funciona melhor quando combinada com expertise humana que pode fornecer contexto, validar conclusões e identificar fatores que talvez não sejam capturados nos dados de telemetria.
A abordagem mais eficaz é tratar os fatos derivados por IA como pontos de partida extremamente embasados para a investigação, mas não como conclusões definitivas. Quando a IA identifica um fato como: “esgotamento do pool de conexões do banco de dados 8 minutos antes do incidente”, isso fornece uma pista valiosa que pode ser verificada rapidamente por meio de uma análise direcionada das métricas do banco de dados e dos logs da aplicação. O fato fornece a você um prazo específico e uma possível causa primária para investigar, o que reduz drasticamente o tempo necessário para identificar o problema em comparação com a pesquisa manual de toda a telemetria disponível.
A qualidade dos dados desempenha um papel crucial na confiabilidade dos fatos derivados por IA. A cobertura abrangente do monitoramento do CloudWatch fornece à IA acesso a informações completas e precisas para análise. Lacunas no monitoramento podem resultar em fatos incompletos ou enganosos, pois a IA só pode trabalhar com os dados disponíveis. Organizações que usam práticas de observabilidade minuciosas, que incluem coleta detalhada de métricas, registro em log abrangente e rastreamento distribuído, têm mais probabilidade de ter fatos derivados por IA precisos e acionáveis em seus relatórios de incidentes.
# Terminologia de relatórios de incidentes
Os termos a seguir são usados nos relatórios de incidentes das investigações do CloudWatch:
Fato derivado por IA
Uma informação ou observação que o sistema de IA considera objetivamente verdadeira ou altamente provável com base em dados, telemetria, logs e padrões históricos disponíveis nos serviços da AWS. Esses fatos são derivados por análise algorítmica e modelos de machine learning e, embora sejam tratados como confiáveis pelo sistema, devem ser submetidos à verificação humana, especialmente em contextos de tomada de decisões importantes. Os fatos derivados por IA podem incluir correlações entre eventos, detecções de anomalias ou inferências sobre o comportamento do sistema que podem não ser imediatamente aparentes para operadores humanos.
Ações corretivas
Etapas específicas e acionáveis recomendadas pelas investigações do CloudWatch para tratar a causa primária de um incidente e evitar sua recorrência, com base nas práticas recomendadas da AWS e no contexto específico dos recursos afetados.
Categorias de fatos
Agrupamentos estruturados de informações relacionadas ao incidente, como métricas de impacto, detalhes sobre a detecção e etapas de mitigação, usados para organizar os dados para geração de relatórios.
Avaliação de impacto
Uma avaliação quantitativa e qualitativa dos efeitos de um incidente na performance do sistema, na experiência do usuário e nas operações da empresa, derivada das métricas do CloudWatch e de dados de outros serviços da AWS adicionados à investigação.
Geração de relatório de incidente
Um processo automatizado que cria uma documentação abrangente sobre um incidente operacional, incluindo cronograma, impacto, causa primária e etapas de resolução, com base nos dados coletados durante uma investigação do recurso de investigações do CloudWatch.
Feed de investigação
Uma exibição cronológica de observações aceitas, hipóteses e notas adicionadas pelo usuário em uma investigação do recurso de investigações do CloudWatch, que serve como o registro principal do progresso e das descobertas da investigação.
Lições aprendidas
Insights gerados automaticamente e oportunidades de aprimoramento identificadas pelo processo de investigação de incidentes, que têm o objetivo de melhorar a confiabilidade do sistema, a eficiência operacional e os recursos de resposta a incidentes em toda a organização.
Relatório de avaliação
Uma avaliação automatizada do relatório do incidente gerado, identificando possíveis lacunas de dados ou áreas que exigem informações adicionais para melhorar a qualidade do relatório e torná-lo mais completo.
Análise da causa primária
Um processo sistemático de identificação do motivo fundamental de um problema operacional, que utiliza as hipóteses e correlações geradas pela IA das investigações do CloudWatch em vários serviços da AWS.
Guia Sugestões
Um atributo das investigações do CloudWatch que apresenta observações e hipóteses geradas por IA sobre possíveis causas ou problemas relacionados, com base na análise de dados de telemetria e logs do sistema.
Eventos do cronograma
Uma sequência cronológica de ocorrências significativas durante um incidente, extraída automaticamente de logs e métricas do CloudWatch, e de dados de outros serviços da AWS para fornecer uma visão geral clara da progressão do incidente.
# Gerar um relatório a partir de uma investigação
Você pode gerar relatórios de incidentes a partir de investigações em andamento ou concluídas. Os relatórios de incidentes gerados no início de uma investigação podem não incluir fatos importantes, como causas primárias e ações recomendadas. Enquanto a investigação está ativa, é possível editar os fatos disponíveis para complementar a investigação com informações adicionais. Depois que a investigação é encerrada, não é mais possível editar nem adicionar fatos à investigação.
**Pré-requisitos**
Antes de gerar um incidente, confirme que os seguintes requisitos foram atendidos:
+ Garanta que o grupo de investigações use a chave do KMS necessária e tenha as políticas de IAM apropriadas associadas ao seu perfil para descriptografar dados dos serviços da AWS. Se seus recursos da AWS estiverem criptografados com chaves do KMS gerenciadas pelo cliente, será necessário adicionar instruções de política do IAM ao perfil do grupo de investigações para conceder às investigações do CloudWatchas as permissões necessárias para descriptografar e acessar esses dados.
+ As seguintes permissões foram concedidas ao perfil do grupo de investigações:
+ `aiops:GetInvestigation`
+ `aiops:ListInvestigationEvents`
+ `aiops:GetInvestigationEvent`
+ `aiops:PutFact`
+ `aiops:UpdateReport`
+ `aiops:CreateReport`
+ `aiops:GetReport`
+ `aiops:ListFacts`
+ `aiops:GetFact`
+ `aiops:GetFactVersions`
**nota**
Você pode adicionar ao perfil do grupo de investigações essas permissões como uma política integrada ou anexar a ele uma política de permissões adicional. Para obter mais informações, consulte, [Permissões para geração de relatórios de incidentes](Investigations-Security.md#Investigations-Security-IAM-IRG).
A nova política gerenciada `AIOpsAssistantIncidentReportPolicy` fornece as permissões necessárias e é adicionada automaticamente aos grupos de investigações criados depois de 10 de outubro de 2025. Para obter mais informações, consulte [AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy).
**Para gerar um relatório de incidente**
1. Abra o console do CloudWatch, em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. No painel de navegação esquerdo, escolha **Operações de IA**, **Investigações**.
1. Escolha o nome de uma investigação.
1. Na página da investigação, em **Feed**, aceite as hipóteses relevantes adicionais e adicione observações à investigação.
**nota**
Para que um relatório seja gerado, é necessário que a investigação tenha pelo menos uma hipótese aceita.
1. No alto da página da investigação, escolha **Relatório do incidente**. Aguarde até que os fatos relevantes da investigação sejam coletados e sincronizados.
1. Na página **Relatório do incidente**, revise os fatos usados para gerar o relatório. Os fatos estão disponíveis no painel direito. Navegue pela guia das categorias de fatos usando as setas para a esquerda e para a direita ou expanda o painel para ver todas as categorias.
1. Escolha **Editar** em um painel de fatos para adicionar ou editar manualmente os dados dessa categoria.
1. Escolha **Visualizar detalhes** em um painel de fatos para ver as evidências corroborantes e o histórico de fatos coletados pelo assistente de IA. Você também pode escolher **Editar** na janela de detalhes dos fatos.
1. Escolha **Adicionar fatos** se quiser fornecer contexto adicional à investigação, como eventos externos ou circunstâncias atenuantes.
1. Depois, escolha **Gerar relatório**.
As investigações do CloudWatch analisarão os dados da investigação e gerarão um relatório estruturado. Esse processo pode levar algum tempo.
1. Revise o relatório gerado no painel de visualização. O relatório incluirá:
+ Eventos do cronograma extraídos automaticamente
+ Análise de causa primária com base em hipóteses aceitas
+ Avaliação de impacto derivada dos dados de telemetria da investigação
+ Ações corretivas recomendadas e lições aprendidas seguindo as práticas recomendadas da AWS
1. Para reter uma cópia do relatório em outro local, escolha copiar e colar o texto do relatório no local desejado.
1. Escolha **Avaliação do relatório** para revisar uma lista das lacunas de dados do relatório. Você pode usar essas informações para coletar dados adicionais para o relatório, atualizar os fatos conforme necessário e gerar novamente o relatório.
# Usar a análise dos Cinco porquês em relatórios de incidentes
Ao gerar relatórios de incidentes, as investigações do CloudWatch podem realizar uma análise dos Cinco porquês da causa primária para identificar sistematicamente as causas subjacentes dos problemas operacionais. Essa abordagem estruturada aprimora os relatórios de incidentes com insights mais profundos e etapas de remediação acionáveis.
Esse atributo usa o Amazon Q para oferecer um chat conversacional. O usuário que fez no login no Console de gerenciamento da AWS deve ter as seguintes permissões:
```
{
"Sid" : "AmazonQAccess",
"Effect" : "Allow",
"Action" : [
"q:StartConversation",
"q:SendMessage",
"q:GetConversation",
"q:ListConversations",
"q:UpdateConversation",
"q:DeleteConversation",
"q:PassRequest"
],
"Resource" : "*"
}
```
[Você pode adicionar essas permissões diretamente ou anexando a política gerenciada [AIOpsConsoleAdminPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html) ou AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html) ao usuário ou ao perfil.
## O que é a análise dos Cinco porquês?
A técnica dos Cinco porquês é uma técnica de análise de causa primária que pergunta “por quê” repetidas vezes para, a partir dos sintomas do incidente, chegar às causas fundamentais. Cada resposta se torna a base para a próxima pergunta, criando uma cadeia lógica que revela a verdadeira causa primária, não apenas os sintomas superficiais.
Durante a geração do relatório do incidente, o recurso de investigações do CloudWatch usa esse método para analisar os resultados da investigação e fornecer uma análise estruturada de causa primária que vai além das falhas técnicas imediatas para identificar problemas de processo, configuração ou problemas sistêmicos.
## Benefícios dos relatórios de incidentes
Existem várias vantagens em incluir um análise dos Cinco porquês nos relatórios de incidentes:
+ **Identificação abrangente da causa primária**: vai além das causas técnicas imediatas para identificar problemas subjacentes de processo ou sistema
+ **Planos de remediação acionáveis**: fornece ações específicas e direcionadas para evitar a recorrência, em vez de correções temporárias
+ **Aprendizagem organizacional**: documenta toda a cadeia causal para futura referência e compartilhamento de conhecimentos pela equipe
+ **Análise estruturada**: garante uma investigação sistemática em vez de resolução pontual de problemas
## Exemplos de cenários em relatórios de incidentes
### Incidente de falha de conexão de banco de dados
**Incidente inicial:** aplicação de comércio eletrônico sofre 500 erros generalizados
1. **Porquê 1:** por que os usuários estão recebendo 500 erros? A aplicação não consegue se conectar ao banco de dados principal.
1. **Por quê 2:** por que a aplicação não consegue se conectar ao banco de dados? A instância do banco de dados não tem mais conexões disponíveis.
1. **Por quê 3:** por que o banco de dados não tem mais conexões? Um trabalho de processamento em lote abriu muitas conexões sem fechá-las corretamente.
1. **Por que 4:** por que o trabalho em lote não fechou as conexões corretamente? O tratamento de erros do trabalho não inclui limpeza de conexão em cenários de falha.
1. **Porquê 5:** por que o tratamento adequado de erros não foi implementado? O processo de revisão de código não inclui verificações específicas dos padrões de gerenciamento de recursos.
**Causa primária:** padrões inadequados de revisão de código para gerenciamento de recursos
**Ações recomendadas:** atualizar a lista de verificação para revisão de código, implementar o monitoramento do grupo de conexões, adicionar detecção automática de vazamento de recursos
### Incidente de degradação de performance
**Incidente inicial:** os tempos de resposta da API aumentaram de 200 ms para 5.000 ms durante o pico de tráfego
1. **Porquê 1:** por que os tempos de resposta aumentaram? A utilização da CPU atingiu 100% em todas as instâncias da aplicação.
1. **Porquê 2:** por que o ajuste de escala automático não adicionou mais instâncias? O ajuste de escala automático foi acionado, mas as novas instâncias não foram aprovadas nas verificações de integridade.
1. **Porquê 3:** por que as novas instâncias não foram aprovadas nas verificações de integridade? O processo de startup da aplicação leva 8 minutos, mais que o tempo limite para verificação de integridade.
1. **Porquê 4:** por que o startup demora tanto? A aplicação baixa grandes arquivos de configuração do S3 a cada startup.
1. **Porquê 5:** por que essa demora no startup não foi considerada na configuração do ajuste de escala automático? O teste de performance foi feito com instâncias pré-aquecidas, não em inícios a frio.
**Causa primária:** a metodologia de teste de performance não reflete cenários de produção com ajuste de escala automático
**Ações recomendadas:** incluir testes com início a frio, otimizar o startup da aplicação, ajustar os tempos limites para verificação de integridade, implementar cache de configuração
### Incidente complexo com análise das ramificações
**Incidente inicial:** os clientes do OpenSearch Serverless experimentaram uma degradação de disponibilidade de 48,3% durante 11 horas
**Cadeia principal de análise:**
1. **Porquê 1:** por que os clientes experimentaram degradação do serviço? A disponibilidade do serviço caiu para 48,3% devido ao ajuste incorreto da escala do receptor.
1. **Porquê 2:** por que o ajuste de escala do ingestor foi incorreto? O CortexOperator reduziu os ingestores de 223 para 174 devido a um erro de cálculo do saldo de AZ.
1. **Porquê 3:** por que o CortexOperator calculou mal o saldo de AZ? O código não conseguiu processar os novos formatos de rótulo do Kubernetes após a atualização para a versão 1.17.
1. **Porquê 4 (ramificação A: técnica):** por que o código não tratou os novos formatos de rótulo? O código esperava rótulos failure-domain.beta.kubernetes.io/zone', mas o Kubernetes 1.17 mudou para 'topology.kubernetes.io/zone'.
1. **Porquê 5 (ramificação A):** por que a compatibilidade com versões anteriores não foi implementada? A alteração no formato da rótulo não foi documentada nas notas da atualização revisadas durante o planejamento da implantação.
**Ramificação B: análise de processo:**
1. **Porquê 4 (ramificação B: processo):** Por que isso não foi detectado nos testes? Os testes de integração usaram clusters pré-configurados com os formatos de rótulos antigos.
1. **Porquê 5 (ramificação B):** por que os testes não incluíram validação dos formatos de rótulos? A configuração do ambiente de testes não refletiu a sequência de atualizações de versão de produção do Kubernetes.
**Causas primárias identificadas:**
+ Técnica: falta de compatibilidade com versões anteriores para alterações de formato de rótulo do Kubernetes
+ Processo: a metodologia de teste não valida impactos de atualização de versão
**Plano de remediação integrado:** implementar a lógica de detecção de formato de rótulo, aprimorar os procedimentos de teste de atualizações, adicionar validação automática de compatibilidade e estabelecer um processo de avaliação de impacto de mudança de versão.
## Usar o fluxo de trabalho guiado dos Cinco porquês
O recurso de investigações do CloudWatch fornece um fluxo de trabalho guiado de análise dos Cinco porquês para ajudar a tratar a falta de fatos e criar relatórios de incidentes mais sólidos. Esse atributo aparece como um fluxo de trabalho sugerido quando o sistema identifica oportunidades para aprimorar a análise de causa primária.
### Experiência de análise interativa
A análise dos Cinco porquês nas investigações do CloudWatch usa uma abordagem interativa baseada em chat que orienta você durante o processo de investigação. Esse método conversacional ajuda a garantir uma análise abrangente, mantendo um fluxo lógico entre as perguntas.
**Principais atributos da experiência interativa:**
+ **Inicialização baseada em fatos**: o sistema apresenta antecipadamente os fatos relevantes da investigação, usando-os para preencher as respostas óbvias e indicando claramente sugestões baseadas em fatos versus sugestões baseadas em inferências
+ **Investigação guiada**: para cada pergunta “por quê”, o sistema sugere respostas com base nos fatos disponíveis, solicita contexto adicional específico e orienta você a considerar aspectos importantes antes de continuar
+ **Gerenciamento de ramificações**: quando são identificados vários fatores contribuintes, o sistema apresenta claramente as opções de ramificação, explica as relações entre elas e ajuda a priorizar as investigações paralelas
+ **Validação progressiva**: para cada resposta, o sistema a reformula para garantir clareza, busca confirmação, destaca os principais insights e conecta as descobertas a um contexto mais amplo
Essa abordagem garante a captura de todas as informações relevantes ao mesmo tempo que mantém o foco nas relações causais mais críticas.
**Acessar o fluxo de trabalho guiado:**
1. Durante a geração do relatório do incidente, revise a seção **Fatos que precisam de atenção** no painel direito.
1. Procure a sugestão da **análise guiada dos Cinco porquês** em **Fluxo de trabalho sugerido**.
1. Escolha **Guie-me** para iniciar o processo interativo dos Cinco porquês.
1. Siga as instruções guiadas para tratar sistematicamente cada pergunta “por quê”, criando uma cadeia causal completa, dos sintomas à causa primária.
O fluxo de trabalho guiado ajuda a garantir a captura de informações abrangentes sobre a causa primária, orientando você em cada etapa da metodologia dos Cinco porquês. Os resultados da análise são incorporados automaticamente ao relatório do incidente, fornecendo documentação estruturada para revisões pós-incidente e aprendizagem organizacional.
Você também pode solicitar uma análise dos Cinco porquês na interface de chat com frases como “Faça uma análise dos Cinco porquês para esse incidente” ou “Qual é a causa primária usando a metodologia dos Cinco porquês?”
## Tratamento de incidentes complexos com várias causas
Alguns incidentes envolvem vários fatores contribuintes que exigem caminhos de análise paralelos. O recurso de investigações do CloudWatch permite a análise das ramificações para garantir que todas as causas significativas sejam identificadas e tratadas.
**Quando a análise de ramificações é necessária:**
+ Várias falhas independentes ocorreram simultaneamente
+ Diferentes componentes do sistema contribuíram para causar o mesmo impacto no cliente
+ Tanto falhas técnicas e quanto falhas processuais desempenharam um papel significativo
+ Falhas em cascata geraram várias cadeias causais
**Processo de análise de ramificações:**
1. **Identificação de ramificações**: o sistema identifica os pontos onde as várias causas convergem ou divergem
1. **Investigação paralela**: cada ramificação é analisada usando a metodologia completa dos Cinco porquês
1. **Mapeamento de conexões**: as relações entre as ramificações são documentadas para mostrar como elas interagem
1. **Resolução integrada**: os planos de remediação tratam de todas as causas primárias identificadas e suas interações
Essa abordagem abrangente garante que incidentes complexos recebam uma análise detalhada e que todos os fatores contribuintes sejam tratados no plano final de remediação.
## Práticas recomendadas para uma análise dos Cinco porquês eficaz
Para maximizar a eficácia da análise dos Cinco porquês em seus relatórios de incidentes, siga estas práticas recomendadas derivadas da experiência operacional:
### Diretrizes para a formulação das perguntas
+ **Comece com o impacto no cliente**: inicie cada análise com o problema enfrentado pelo cliente para manter o foco no impacto nos negócios
+ **Aumente a profundidade técnica progressivamente**: passe do impacto nos negócios para os detalhes técnicos à medida que avançar pelas perguntas
+ **Mantenha a progressão lógica**: garanta que cada resposta leve naturalmente à próxima pergunta, sem lacunas lógicas
+ **Inclua evidências corroborantes**: consulte métricas, logs ou eventos de cronograma específicos para validar cada resposta
### Validação da análise
Valide a análise dos Cinco porquês usando estes critérios:
+ **Fluxo lógico**: progressão clara dos sintomas até a causa raiz, sem pular nenhuma etapa
+ **Precisão técnica**: terminologia correta, descrições precisas do comportamento do sistema e interações válidas de componentes
+ **Completude**: a análise explica todos os sintomas observados e chega a uma causa fundamental que, se tratada, evitaria a recorrência
+ **Acionabilidade**: a causa primária identificada leva a ações de remediação específicas e implementáveis
### Armadilhas comuns a serem evitadas
+ **Parar nos sintomas**: não conclua a análise na primeira falha técnica; continue até chegar às causas sistêmicas ou processuais
+ **Análise focada em culpa**: concentre-se nas falhas de sistema e de processo, não em ações individuais
+ **Uma única linha de raciocínio**: considere os vários fatores contribuintes e use a análise das ramificações quando apropriado
+ **Evidências insuficientes**: garanta que cada resposta seja corroborada por dados concretos da investigação
### Integração com seções do relatório do incidente
A análise dos Cinco porquês se integra a outras seções do relatório do incidente para fornecer uma documentação abrangente:
+ **Correlação com o cronograma**: cada pergunta “por quê” pode referenciar eventos específicos do cronograma, fornecendo um contexto temporal às relações causais
+ **Validação por métricas**: as respostas são corroboradas por métricas e gráficos que demonstram os comportamentos técnicos descritos
+ **Alinhamento com a avaliação de impacto**: o primeiro “porquê” está diretamente relacionado às métricas de impacto para o cliente, documentadas na seção de avaliação de impacto
+ **Fundamento para lições aprendidas**: as causas primárias identificadas por meio da análise dos Cinco porquês embasam diretamente as seções sobre lições aprendidas e ações corretivas
Essa integração garante consistência em todo o relatório do incidente e fornece às partes interessadas uma narrativa completa e coerente, partindo dos sintomas iniciais, passando pela causa raiz, chegando aos planos de remediação.