O que faz
RCA é a sigla de root cause analysis — a análise de causa raiz: a revisão estruturada, baseada em evidências, de como um incidente de fato aconteceu. Insira os eventos de um incidente como uma pequena linha do tempo estruturada — cada evento com um tipo (mudança feita, sintoma começou, alerta disparou, detectado, mitigado, resolvido e assim por diante), uma ordem que você controla e uma nota opcional — e marque quais domínios de fator contribuinte você observou. Um registro fixo de sete regras originais dispara de forma determinística e produz três coisas. Primeiro, uma linha do tempo ordenada e rotulada, com os marcos de detecção, mitigação e resolução destacados e os intervalos entre eles derivados (em número de eventos, porque a ferramenta não tem relógio e quem controla a ordem é você). Segundo, um conjunto de fatores contribuintes candidatos a investigar, extraídos de nove domínios, cada um com as evidências que o confirmariam e, tão importante quanto, as evidências que o descartariam. Terceiro, notas sobre a própria completude da linha do tempo (nenhum marco de detecção registrado, um intervalo longo até a detecção, nenhuma mudança na linha do tempo) e ressalvas sobre a entrada. Um clique exporta um esqueleto de RCA em Markdown para a revisão.
O que deliberadamente não é
Esta ferramenta nunca aponta uma causa-raiz. É esse o ponto dela. Um RCA é escrito por pessoas a partir de evidências, em uma revisão de verdade; ela dá a estrutura desse trabalho organizando os candidatos e a evidência que cada um exigiria, para que nada seja esquecido e nenhuma conclusão seja precipitada. Um fator só é mostrado como confirmado quando você marca o controle "marcar confirmado" dele, e sempre é atribuído a você, nunca afirmado pela ferramenta. Ela não atribui culpa, não faz conexões de rede, não pede credenciais e não substitui nem uma revisão pós-incidente nem um RCA do fornecedor. As notas em texto livre fluem apenas para o esqueleto exportado; nunca influenciam quais regras disparam.
Como o esqueleto é montado — e como é verificado
A linha do tempo é ordenada pela posição que você dá a cada evento; o motor não lê relógio algum. Os intervalos entre marcos são relatados como o número de eventos entre dois marcos, não como tempo de relógio, que a ferramenta não tem como saber. Cada domínio de fator contribuinte que você observa vira um candidato; a linha do tempo pode acrescentar outros (uma mudança na linha do tempo adiciona o candidato de mudança recente; um intervalo longo até a detecção adiciona o candidato de lacuna de monitoramento e uma nota estrutural). Todo candidato carrega evidências tanto de confirmação quanto de descarte, porque um esqueleto honesto mostra como fechar uma questão de qualquer um dos lados. O painel "Por que estes candidatos?" lista cada regra que disparou com o seu motivo, de modo que a estrutura é auditável, não oracular.
Como não existe um único esqueleto "correto" para uma ferramenta consultiva, os vetores de ouro clássicos não se aplicam. O modelo de verificação — a decisão firmada pelo piloto do Construtor de Hipóteses de Falha para toda a família de Operações e Trabalho de Campo — é o de vetores-instantâneo de disparo de regras: para cada entrada de teste, o build afirma exatamente quais regras disparam, a linha do tempo ordenada exata, os intervalos de marco exatos, a lista de candidatos exata com o sinalizador de confirmação de cada um, as notas estruturais exatas e as ressalvas exatas. Doze vetores (seis cenários, seis rejeições) fixam o registro atual. Um deles é uma invariante de linguagem verificada por máquina: nenhum candidato pode ser marcado como confirmado a menos que a entrada o confirme, de modo que a disciplina de não apontar causa-raiz é imposta pelo build, não apenas pela intenção.
Entrada da API
O ponto de entrada com paridade de API recebe um objeto JSON: {"events": [{"id", "kind", "order", "note"}], "factors": [{"domain", "confirmed"}], "notes": {"summary", "followups"}}. Os tipos de evento e os domínios de fator usam os vocabulários fechados mostrados no formulário; um valor fora do vocabulário é um erro de formato, nunca um palpite. events não pode estar vazio; cada evento precisa de um id e de uma ordem numérica; cada fator precisa de um sinalizador booleano confirmed.