# Construtor de Linha do Tempo e RCA de Incidente > RCA é a sigla de root cause analysis, a análise de causa raiz - o caminho disciplinado dos sintomas de um incidente de volta às condições que o permitiram. Insira os eventos de um incidente como uma pequena linha do tempo e marque os domínios de fator contribuinte que você observou; um conjunto fixo de regras ordena a linha do tempo, deriva os intervalos entre marcos e estrutura fatores contribuintes candidatos com a evidência de cada um. Nunca aponta uma causa-raiz - candidatos a investigar, não um veredito. - Tool: https://ronutz.com/pt-BR/tools/incident-timeline-rca-builder - Family: Operações e fieldcraft --- ## 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`. ## Standards and references - Original incident-RCA ruleset (D-18: original by construction) - the 7-rule registry, 9 contributing-factor domains with confirm/rule-out evidence, milestone/duration-band derivation, structural-completeness notes, and quality warnings are original editorial work encoding standard post-incident-review practice (timeline ordering, milestone spans, contributing-factor structuring, the no-root-cause-without-evidence discipline); no external framework or specification is claimed or reproduced ## Related reading - [Atualizações e Gestão de Mudanças: Operando Mudança numa Plataforma Que Também Muda Sozinha](https://ronutz.com/pt-BR/learn/zscaler-platform-updates-and-change-management.md): Uma plataforma de segurança em nuvem tem três correntes de mudança - a nuvem do fornecedor, a sua frota de agentes e a sua política - e só as duas últimas recebem as suas ordens. O que o admin de fato governa: as Update Settings do Client Connector e os sumários de release por ano para a frota, o audit log como registro de mudanças de política, e as disciplinas de rollout em anéis e janela de congelamento, que são prática de operador sobre os controles documentados, declaradas como tal. - [Causa-Raiz É um Verbo, Não um Substantivo](https://ronutz.com/pt-BR/learn/root-cause-is-a-verb-not-a-noun.md): A expressão causa-raiz convida a um único vilão e a um final arrumadinho. Incidentes reais raramente têm um; têm fatores contribuintes, e o trabalho honesto é estruturar os candidatos e a evidência que confirmaria ou descartaria cada um — não nomear um culpado antes de a evidência chegar. - [Eventos e Advanced Analytics da Netskope: Do Tráfego à Evidência](https://ronutz.com/pt-BR/learn/netskope-advanced-analytics.md): Todo objetivo de monitoramento em todo blueprint Netskope - event monitoring, event analysis, application discovery, event sharing - se resolve numa disciplina subjacente: o modelo de eventos da plataforma e o que se constrói sobre ele. Como a inspeção inline e via API vira eventos de página, aplicação, alerta e auditoria; como o Skope IT responde 'o que acabou de acontecer' enquanto o Advanced Analytics responde 'o que vem acontecendo'; e como eventos saem da plataforma - transmitidos ao SIEM e ao ferramental do SOC - para a nuvem de segurança virar fonte de evidência de primeira classe. - [O Alerta de Exfiltração: Um Passo a Passo do Sinal à Resposta de Postura](https://ronutz.com/pt-BR/learn/zscaler-exfiltration-response-posture.md): Um alerta de suspeita de exfiltração de dados é o cenário em que toda a série Zscaler converge: leia o alerta contra os campos de log, estabeleça o que a inspeção podia de fato ver, percorra os planos de DLP e CASB pelo que saiu e pelo que repousa exposto, verifique os corredores não-web do firewall, e responda com mudanças de postura - isolamento para o cinzento, bypasses apertados, vigilância de contagem de bytes - em vez de um único bloqueio heroico. - [O Audit Log de Administradores: Quem Mudou o Quê, De Onde, Com Que Resultado](https://ronutz.com/pt-BR/learn/zscaler-admin-audit-logs.md): O ZIA registra toda ação de admin - console e API igualmente - como um registro de auditoria de anatomia precisa: timestamp, ação, categoria e subcategoria, recurso, admin, IP do cliente, interface, resultado e um diff de antes/depois. O bloqueio de cinco-falhas-num-minuto que se escreve no próprio log, a janela de retenção de seis meses, como a trilha flui para um SIEM, e como lê-la em busca de escalada de privilégios.