Você conhece o que é Fault Tree Analysis (FTA)? Podemos também chamar de Análise da Árvore de Falhas numa tradução direta. A FTA é uma abordagem estruturada usada para identificar as causas potenciais de falhas em sistemas, todo tipo de sistema e processos. Essa técnica é amplamente aplicada em áreas como engenharia, segurança, gestão de risco e qualidade, e por que não em DevOps e SRE.

Num contexto de guerra, entre os anos 1960-1970, a Bell Telephone Laboratories desenvolveu para a Força Aérea Americana para avaliar um projeto de sistema de lançamento de mísseis balísticos. Pouco tempo depois, a Boeing começou a usar FTA em proetos de aeronaves, a técnica foi adaptada para a indústria aeroespacial, especialmente na NASA, para garantir a segurança de missões tripuladas, como o programa Apollo.

O objetivo da Análise da Árvore de Falhas é sistematizar processos que ajudam a identificar, entender e mitigar as causas potenciais de falhas em sistemas complexos. Por exemplo, ao colocar um produto no ar composto por componentes tipo: 30 micro serviços em kubernetes, 20 filas, 5 bancos de dados, 10 fluxos de entrada, 20 fluxos de saída. Como entender tudo isso, e pior, como explicar para alguém como um sistema desse funciona? A FTA é uma abordagem gráfica e lógica que mapeia as relações de causa e efeito entre falhas e eventos indesejados que trazem problemas para o sistema. Vejamos alguns elementos básicos de uma Árvore de Falhas:

• Evento Topo: Representa o objetivo da análise, ou seja, a falha crítica a ser evitada.
• Eventos Básicos: Causas primárias que não podem ser mais subdivididas.
• Portas Lógicas:
  • AND: Todas as entradas devem ocorrer para que o evento de saída ocorra.
  • OR: Qualquer entrada pode causar o evento de saída.

Esses elementos se relacionam de uma forma bastante específica. Na hierarquia, o evento topo está no nível superior, na parte mais alta do gráfico. Os eventos básicos formam a base, e esses são conectados por meio de portas lógicas para formar sub eventos, gerando fluxo de causa e efeito.

A análise da árvore permite entender quais combinações de falhas causam o evento topo, ajudando a identificar as áreas mais críticas.

Entendendo as portas lógicas

Léo, não entendi nada desse lance de portas lógicas, WTF?!? Calma, calma jovem!!! Vamos aos detalhes…. Imagine a seguinte situação: você precisa sacar dinheiro num caixa eletrônico, certo? Quais são as condições para isso ocorrer? Quais são as condições para isso não ocorrer?

Porta AND

A porta AND também é chamada de Porta E, o evento de saída ocorre apenas se TODOS os eventos de entrada ocorrerem. Para sacar dinheiro você precisa de: (1) Ter um cartão válido AND (2) Ter a biometria AND (3) Saber a senha AND (4) Ter saldo.

graph TD
    A[Sacar dinheiro]
    B[Ter um cartão válido]
    C[Ter a biometria]
    D[Saber a senha]
    E[Ter saldo]
    A[Sacar dinheiro] -->|AND| B
    A -->|AND| C
    A -->|AND| D
    A -->|AND| E

O Evento Principal, Sacar dinheiro ocorre somente se Evento 1 E Evento 2 E Evento 3 E Evento 4 acontecerem ao mesmo tempo.

Porta OR

No caso de uma porta OR, também chamada de Porta OU, o evento de saída ocorre se QUALQUER UM dos eventos de entrada ocorrer. Para sacar dinheiro você precisa de: (1) Ter um saldo válido na conta corrente OR (2)Ter um saldo válido na conta poupança.

graph TD
    A[Para sacar dinheiro]
    B[Ter um saldo válido na conta corrente]
    C[Ter um saldo válido na conta poupança]
    A -->|OR| B
    A -->|OR| C

O Evento Principal ocorre se Evento 1 OU Evento 2 ocorrerem.

FTA saque de dinheiro

graph TD
    A[Não consigo realizar o saque do dinheiro] --> B(Saldo insuficiente)
    A --> C(Falha no terminal)
    A --> D(Cartão bloqueado)
    A --> E(Limite diário atingido)
    A --> F(Biometria e senha inválida)

    B --> B1(Débitos recentes reduziram o saldo)
    B --> B2(Erro no cálculo do saldo)

    C --> C1(Problema de conexão com o banco)
    C --> C2(Falha de hardware no terminal)

    D --> D1(Suspeita de fraude)
    D --> D2(Expiração do cartão)

    F --> F1(Falha Senha)
    F --> F2(Falha Biometria)

DevOps e SRE

No dia a dia de um engenheiro DevOps/SRE faz parte criar infraestruturas e resolver problemas em infraestruturas. Mas como conhecer todos os componentes de uma empresa? Como saber por onde começar a fazer uma análise de causa raiz se eu nem sei onde fica o ponto inicial? Nas documentações dos projetos, nos runbooks é de fundamental importância documentar processos de diagnósticos de causa raiz de problemas. Vejam alguns exemplos que pode ajudar o seu trabalho

Time_out de serviço de API

Uma das APIs do seu sistema apresenta erros de time_out como inciar um processo de troubleshooting desse componente? Veja por onde começar:

graph TD
    A[Timeout no serviço de API] --> B(Alta latência na rede)
    A --> C(Sobrecarga do servidor)
    A --> D(Configuração incorreta do timeout)

    B --> B1(Problemas de roteamento)
    B --> B2(Congestionamento na rede)
    B --> B3(Perda de pacotes)

    C --> C1(Volume inesperado de requisições)
    C --> C2(Recurso insuficiente: CPU/memória)
    C --> C3(Erro no balanceamento de carga)

    D --> D1(Timeout configurado muito curto)
    D --> D2(Faltando configurações para operações demoradas)

Erros em um POD

Uma situação bastante comum, um dos PODs não sobe por que apresenta erros, veja como inciar um processo de análise de causa raiz por meio da FTA:

graph TD
    A[POD não inicia no Kubernetes] --> B(Variável de ambiente ausente)
    A --> C(Valor incorreto na variável de ambiente)
    A --> D(Variável de ambiente não compatível com o container)

    B --> B1(Variável não definida no manifest YAML)
    B --> B2(ConfigMap ou Secret não montado corretamente)

    C --> C1(Tipo de dado incompatível)
    C --> C2(Erro de sintaxe ou formatação)
    C --> C3(Referência inválida ao ConfigMap ou Secret)

    D --> D1(Imagem do container com erro de leitura)
    D --> D2(Script de inicialização não suporta o valor fornecido)

Resumo final

A Análise da Árvore de Falhas (FTA) é como um mapa da mina para times de DevOps e SRE, mostra exatamente onde estão os perigos escondidos antes que o caos aconteça. Lidar com sistemas complexos e críticos significa que não dá pra contar só com a sorte, como diz a primeira lei de SRE, “esperança não é uma estratégia”, falhas podem custar caro, tanto em dinheiro quanto em sono perdido. Com a FTA, você consegue visualizar as causas raiz dos problemas, priorizar soluções e deixar sua infraestrutura pronta para suportar as demandas. Ela é sua aliada na hora de aumentar a confiabilidade e reduzir panes inesperadas. Evitar dor de cabeça, perda de uma noite de sono e garantir que seus usuários acessem as aplicações são nossos objetivos finais.

Abraços!

Vida longa e próspera a todos!!

Referências

• FTA - Sacar Dinheiro
• FTA API
• FTA POD
• https://en.wikipedia.org/wiki/Fault_tree_analysis
• https://ntrs.nasa.gov/api/citations/20000070463/downloads/20000070463.pdf
• Fault Tree Handbook with Aerospace Applications

MENTORIA

Curtiu o blog? Quer trocar uma ideia comigo sobre algum post?

Marca Aqui! É um papo gratuito oferecido para quem é leitor do blog, podemos falar de temas como: DevOps, SRE e carreira em TI.

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.