Root Cause Analysis

1) O que é RCA e o que é necessário

Root Causa Analisis - um processo estruturado para identificar as causas da raiz do incidente para eliminar a repetição. No centro estão factos, causais e melhorias sistêmicas (processos, arquitetura, testes), em vez de encontrar culpados.
Objetivos: prevenir reincidência, reduzir MTTR/frequência de incidentes, melhorar o SLO, fortalecer a confiança de reguladores e parceiros.

2) Princípios (Just Cultura)

Sem acusações. Não punimos as pessoas, punimos as práticas de risco.
Factual. Apenas os dados e artefactos verificáveis.
Um olhar E2E. De cliente a backand e provedores.
A verificabilidade das hipóteses. Qualquer afirmação é com teste/experiência.
Um curto-circuito CAPA. Medidas corretivas e de prevenção com proprietários e prazos.

3) Artefatos de entrada e preparação

Timeline UTC: T0 detecção → T + ação → T + restauração.
Os dados de observabilidade são logs, métricas, trailers, sintéticos, status da página.
Mudanças: lançamentos, bandeiras de fich, configs, eventos de provedor.
Ambiente: versões, hash artefactos, SBOM, marcas de infraestrutura.
Base de ocorrência: descrição do impacto (SLO/SLA, clientes, circulação), decisões tomadas, workaround' s.
Chain of custody: Quem e quando coletou/alterou as provas (importante para a complacência).

4) Técnicas RCA: quando qual

1. 5 Why - descobrir rapidamente a cadeia causal para problemas estreitos. Risco: «reduzir» o sistema complexo para a régua.
2. Diagrama Ishikawa (Fishbone) - Descomposição de fatores em categorias: People/Processo/Plataforma/Policy/Partner/Product. Faz bem no início.
3. Fault Tree Analisis (FTA) - Dedução de evento para conjunto de causas (AND/OR). Para infraestrutura e falhas de madeira.
4. Causal Graph/Event Chain é um gráfico de dependências com probabilidades e peso de contribuição. Bom para microsserviços e provedores externos.
5. FMEA - Prevenção: modos de falha, gravidade (S), frequência (O), detectividade (D), RPN = S x O x D.
6. Mudar Analisis - compara «como foi/como foi» (diff configs, schema, versões).
7. Human Factors Review - contexto de decisões humanas (fadiga de alertas, playbooks ruins, superaquecimento).

O laço recomendado é Fishbone → Mudança Analisis → Causal Graph/FTA → 5 Why em ramos-chave.

5) Passo a passo RCA

1. Iniciar: designar o dono do RCA, definir a data de lançamento do relatório (por exemplo, 5 dias úteis) e montar o comando (IC, TL, Scribe, provedores).
2. Recolher os factos: timeline, gráficos, lançamentos, logs, artefactos; fixar versões e controle de quantias.
3. Mapear o impacto: quais são os SLI/SLO afetados, quais são os grupos (países, provedores, VIP).
4. Construir hipóteses primárias, alternativas; assinalar os testes agora.
5. Verificar hipóteses: reprodução em stage/simulação/canário, análise de trailers, fault inhation.
6. Identificar as causas de raiz e contribuinte, tecnologia, processo, organização.
7. Formar CAPA: corriqueiros (corrigir) e avisantes (impedir); métricas de sucesso e prazos.
8. Concordar e publicar o relatório: base interna de conhecimento +, se necessário, versão externa para clientes/reguladores.
9. Comprovar o efeito: pontos de controle em 14/30 dias; encerrar as ações.

6) O que é considerado «causa raiz»

• testes fracos/flagras, limites/alertas ausentes, documentação ambígua, default incorreto, arquitetura frágil.
• Muitas vezes é uma combinação de fatores (configuração x falta de gate x carga x provedor).

7) CAPA: medidas corretivas e de advertência

• fixes de código/configs, reversão de pattern, alteração de limites/temporizações, adição de índices, réplica/charding, reposição de tráfego, atualização de certificados.

• testes (contratados, maletas de caos), alerts (burn rate, quórum sintético), política de lançamentos (canary/blue-green), GitOps de configs, treinamento/cheque-folhas, duplicação de provedor, ensinamentos de DR..

Cada ação: proprietário, deadline, efeito esperado, métrica de verificação (por exemplo, redução de mudança-failure-rate de X%, ausência de repetições de 90 dias).

8) Verificação de hipóteses e efeitos

Experimentos: fault inhation/chaos, tráfego shadow, configs A/B, carregados com perfis reais.
Métricas de sucesso: recuperação do SLO, estabilização p95/p99, falta de picos de erro-rate, redução de MTTR, tendência de burn-rate e zero-reopen por 30 dias.
Pontos de referência: D + 7, D + 30, D + 90 - revisão da execução do CAPA e do impacto.

9) Modelo de relatório RCA (interno)

1. Resumo, o que aconteceu quando, quem foi afetado.
2. Impacto: SLI/SLO, usuários, regiões, circulação/multas (se houver).
3. Timeline (UTC): eventos principais (alertas, decisões, lançamentos, registros).
4. Observações e dados: gráficos, logs, traçados, configs (difs), estatais de provedores.
5. Suposições e verificações: as referências aceitas/rejeitadas às experiências.
6. Razões de raiz, tecnologia, processo, organização.
7. «Por que não repararam ou não pararam».
8. Plano CAPA: tabela de ações com proprietários/prazos/métricas.
9. Riscos e vulnerabilidades residuais - o que ainda precisa ser monitor/testado.
10. Anexos: artefatos, links, gráficos (lista).

10) Exemplo (breve, resumido)

Evento: queda do êxito de pagamentos no 35% às 19: 05-19: 26 (SEC-1).
Impacto: e2e-SLO 21 minas violadas, 3 países afetados, reembolsos/compensações.
Razão 1: a nova versão do validador do cartão aumentou a latência para 1. 2 com → de tempo para o provedor.
Razão 2: Faltando canary para o provedor «A», o lançamento foi 100%.
Motivo 3 (org): O limite de alert do SLI de negócios não abrangia uma faixa de BIN específica (grupo VIP).
CAPA: recuperar a versão antiga do validador; digitar canary 1/5/25%; adicionar um SLI de negócios para os cômodos BIN; negociar um failover de 30% para o provedor «B»; «slow upstream».

11) Métricas de maturidade do processo RCA

Cumprir CAPA dentro do prazo (% fechado em 30 dias).
Reopen rate (incidentes reabertos em 90 dias).
Mudar-failure-rate antes/depois.
Proporção de incidentes onde se encontram causas sistêmicas (não apenas «erro humano»).
Cobertura de testes de novos cenários RCA.
Hora de lançamento do relatório (SLA publicação).

12) Características dos domínios regulados (fintech/iGaming etc.)

Relatórios para fora: versões de clientes/reguladores do relatório sem detalhes sensíveis, mas com planos de prevenção de repetições.
Auditoria-logos e imutabilidade: armazenamento de artefatos, relatórios assinados, vinculação a tíquetes, CMDB, logs de lançamento.
Dados dos usuários: despersonalização/camuflagem em exemplos de logs.
Data de notificação: vincular a contratos e normas (por exemplo, N relógio para notificação inicial).

13) Anti-pattern

«A culpa de Vasa» é uma paragem no fator humano sem razões sistêmicas.
A falta de verificação de hipóteses é uma conclusão intuitiva.
RCA total demais («o serviço estava sobrecarregado») - sem alterações específicas.
Sem CAPA ou sem proprietários/prazos - relatório para relatório.
A ocultação de informações é uma perda de confiança, impossibilidade de treinamento da organização.
Sobrecarregamento de métricas sem ligação com SLO/Business SLI.

14) Ferramentas e práticas

Armazenamento RCA (wiki/knowledge base) com metadados de serviço, SEV, razões, CAPA, status.
Modelos e bots: geração de esqueleto de relatório a partir do incidente (timeline, gráficos, lançamentos).
Gráfico de causalidade: construção de um mapa de causa e evento (por exemplo, baseado em logs/trailers).
Diretório Chaos: cenários para reproduzir incidentes passados em um stage.
Dashboards «após RCA»: widgets individuais que confirmam o efeito CAPA.

15) Folha de cheque «pronta para publicação»

• A timeline e os artefatos estão completos e testados.
• Causas de raiz definidas e comprovadas por testes/experiências.
• As causas de raiz e contribuintes estão separadas.
• CAPA contém proprietários, prazos, métricas de efeito mensuráveis.
• Há um plano de verificação dentro de 14/30 dias.
• Versão para steakhalders externos preparada (se necessário).
• O relatório passou por aquelas/reviravoltas.

16) Resultado

O RCA não é uma retrospectiva para a formalidade, mas um mecanismo de aprendizagem do sistema. Quando os factos são coletados, a causalidade é comprovada e os CAPA são fechados em métricas e testados por experimentos, a organização é cada vez mais resistente: o SLO é mais estável, o risco de reincidência é menor e a confiança dos usuários e reguladores é maior.