Usar a análise dos Cinco porquês em relatórios de incidentes - Amazon CloudWatch

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 ou AIOpsOperatorAccess 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  2. 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.

  3. 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.

  4. Porquê 4: por que o startup demora tanto? A aplicação baixa grandes arquivos de configuração do S3 a cada startup.

  5. 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.

  2. 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.

  3. 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.

  4. 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'.

  5. 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.

  2. 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.

  2. Procure a sugestão da análise guiada dos Cinco porquês em Fluxo de trabalho sugerido.

  3. Escolha Guie-me para iniciar o processo interativo dos Cinco porquês.

  4. 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

  2. Investigação paralela: cada ramificação é analisada usando a metodologia completa dos Cinco porquês

  3. Mapeamento de conexões: as relações entre as ramificações são documentadas para mostrar como elas interagem

  4. 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.