Por que as falhas de sistema acontecem? As causas mais comuns

As falhas de sistema concentram-se em cinco causas: mudança recente em produção, esgotamento de recurso, dependência externa que degrada sem parar, erro de configuração e falha em cascata. Identificar qual delas originou o incidente exige correlacionar mudança e consumo com desvio de comportamento sobre o mapa de dependências, porque o componente com pior sintoma quase nunca é o que começou.

Ambientes distribuídos mudam o tempo todo, e cada mudança altera premissas que o desenho original tratava como estáveis. É daí que vêm as falhas, e as causas mais frequentes formam um conjunto pequeno e reconhecível: cinco delas respondem pela maior parte dos incidentes em sistemas críticos.

A causa mais frequente também é a mais banal: alguém alterou algo em produção. Depois dela vêm o esgotamento de recurso, a dependência externa que degrada sem parar, o erro de configuração e a falha em cascata, que transforma um problema local em indisponibilidade ampla.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

Mudança recente em produção

A causa mais frequente de falha é a mudança que acabou de entrar em produção.

Sistemas estáveis raramente quebram sozinhos. Quebram depois de um deploy, de uma alteração de parâmetro, de uma atualização de biblioteca ou de uma migração de dados. Quando um serviço que funcionava há semanas para de responder, a primeira pergunta útil é o que mudou no ambiente desde a última entrega.

A dificuldade não está na hipótese, está na verificação. Em ambiente com muitas equipes entregando de forma independente, várias mudanças convivem na mesma janela, e nem todas passam pelo mesmo processo de registro. Alteração feita direto no console de nuvem, ajuste manual de limite em banco de dados e rotação de credencial quase nunca aparecem no mesmo lugar em que os deploys aparecem.

O deploy observado resolve boa parte desse problema. A prática trata cada entrega como evento de telemetria, marcado no tempo, associado ao serviço afetado e comparável com o comportamento anterior. A plataforma Dynatrace registra a mudança e avalia se os indicadores daquele serviço permaneceram dentro do padrão aprendido depois dela.

Para o profissional de DevOps, o registro de cada entrega como evento de telemetria substitui a discussão sobre quem quebrou o ambiente por evidência de qual entrega saiu do padrão. Para o Site Reliability Engineer, ou SRE, o mesmo registro encurta o tempo médio de resolução do plantão, porque a lista de suspeitos chega ordenada por horário e por serviço.

Existe um efeito de segunda ordem que interessa ao gerente de infraestrutura. Mudança registrada como evento permite reverter com critério, em vez de reverter tudo o que entrou no dia por precaução. Reversão indiscriminada custa entrega perdida, e entrega perdida também é custo.

Esgotamento de recurso

A segunda causa é o recurso que acaba, e ela quase nunca acontece de repente.

Memória, espaço em disco, pool de conexão com o banco de dados, threads de aplicação e profundidade de fila são recursos finitos. O consumo cresce por acúmulo, ao longo de dias ou de semanas, e o sistema segue respondendo enquanto houver folga. Quando a folga termina, a degradação aparece de uma vez e parece súbita. O gráfico de consumo, examinado depois do incidente, mostra uma reta subindo desde muito antes.

Vazamento de memória é o exemplo clássico dessa categoria. Cada requisição retém um pouco mais do que devolve, o coletor de lixo trabalha mais para liberar o mesmo espaço, o tempo de resposta sobe e o orquestrador reinicia o processo. O sintoma visível é a reinicialização, e a causa está em código que rodou por muito tempo sem sinal aparente.

Pool de conexão esgotado produz um sintoma enganoso. A aplicação fica lenta e o banco de dados aparece saudável, porque o gargalo está na fila de espera por conexão e não na execução da consulta. Equipes que olham apenas o servidor de banco perdem tempo procurando no lugar errado.

Fila de mensagens tem comportamento próprio. Enquanto o consumo acompanha a produção, a fila não guarda nada relevante e o painel mostra profundidade próxima de zero. Basta o consumidor ficar mais lento que o produtor por um intervalo curto para o acúmulo virar atraso visível na operação de negócio.

Para o gerente de infraestrutura, esgotamento de recurso é a falha que a previsão de capacidade evita, desde que a tendência de consumo seja acompanhada por meses e não por dias. Para o CIO, é a categoria de incidente mais simples de traduzir em decisão de investimento, porque o custo da indisponibilidade se compara com o custo do recurso adicional.

Recurso que acaba avisa antes, em dado que ninguém estava observando.

Dependência externa

A terceira causa vem de fora do perímetro que a equipe controla.

Aplicações modernas dependem de serviços que não pertencem a quem as opera: meio de pagamento, autenticação federada, serviço de mensageria, interface de órgão regulador, resolução de nomes, armazenamento de objetos. Cada dependência é um ponto de falha herdado. A indisponibilidade total do fornecedor é o caso simples, porque fica evidente em poucos minutos.

O caso difícil é a degradação parcial. O serviço externo continua respondendo, só que devagar, e a aplicação que o chama mantém conexões abertas à espera de resposta. Threads ficam presas, o pool esgota e o sistema para de atender, inclusive nas operações que não dependiam daquele fornecedor. Uma lentidão moderada do lado de fora vira indisponibilidade ampla do lado de dentro.

A assinatura da dependência externa é específica e reconhecível. O tempo de processamento dentro do código próprio permanece estável, e o tempo total da transação cresce. A espera acontece fora do perímetro da aplicação.

O rastreamento distribuído mostra a chamada externa dentro do trace, com o tempo gasto em cada etapa. O trace é o GPS da viagem da requisição, mostrando cada parada do trajeto. Sem essa visão, a lentidão do fornecedor aparece como lentidão da aplicação própria, e a equipe corrige o sintoma no lugar da causa.

Para o SRE, dependência externa é o item que mais distorce o orçamento de erro, a margem de indisponibilidade tolerada derivada do objetivo interno de disponibilidade. Ela consome tempo tolerado sem que a equipe tenha ação direta sobre a origem. Para o CTO, é o argumento que sustenta a exigência de compromisso contratual com fornecedores críticos, e o Service Level Agreement, ou SLA, deixa de ser formalidade nesse ponto.

Erro de configuração

A quarta causa é a mais banal de todas e também a mais custosa.

Erro de configuração não exige código novo. Um valor de tempo limite trocado, um limite de memória definido abaixo do necessário. Uma regra de firewall aplicada no ambiente errado, um certificado vencido sem renovação agendada. Uma variável apontando para o banco de homologação. Nenhum desses itens aparece em revisão de código, porque nenhum deles é código.

Certificado vencido é caso à parte. É a falha mais previsível que existe, tem data marcada com antecedência, e continua derrubando serviço em produção com regularidade. O motivo é organizacional antes de ser técnico: o certificado pertence a todo mundo e a ninguém. Quando o inventário de certificados não está em painel algum, a data só é lembrada depois que o navegador do usuário recusa a conexão.

Configuração divergente entre ambientes produz o incidente mais frustrante da lista. O código passou em todos os testes, o comportamento em homologação foi correto, e a falha aparece só em produção porque só ali o valor é diferente. Rastrear a divergência entre ambientes sem inventário versionado consome tempo que o compromisso de disponibilidade não tem.

Para o time de DevOps, tratar configuração como código, versionada e revisada como qualquer entrega, remove a maior parte dessa categoria. O ganho real aparece na reversão: desfazer um parâmetro passa a ser uma operação registrada, com autor e horário, em vez de memória de quem estava de plantão.

Inventário confiável de parâmetros e de dependências raramente existe pronto quando o incidente chega. Levantá-lo junto com a implantação da plataforma Dynatrace, em vez de reconstruí-lo sob pressão durante o plantão, é a prática que a Rike IS aplica em ambiente que não pode parar.

Falha em cascata

A quinta causa não é um evento isolado, e sim o mecanismo que transforma um problema pequeno em indisponibilidade ampla.

Falha em cascata começa com um componente que degrada e termina com serviços que nunca dependeram dele fora do ar. O caminho é conhecido. Um serviço fica lento, quem o chama acumula requisições em espera, a fila cresce, o consumo de memória sobe e o segundo serviço também degrada. Repetido salto após salto, o efeito atravessa o ambiente inteiro.

A tentativa de recuperação costuma agravar a cascata. Clientes que recebem erro tentam de novo, e a nova tentativa multiplica a carga sobre o componente que já estava saturado. Reiniciar um serviço com fila acumulada devolve todo o trabalho represado de uma vez, e a reinicialização vira o segundo incidente.

Conter a propagação depende de decisões de arquitetura tomadas antes do incidente. Reconhecer a cascata enquanto ela acontece é outro problema, e o sinal característico está na ordem dos alertas no tempo, porque o componente que degradou primeiro raramente é o que grita mais alto.

Para o gerente de infraestrutura, a cascata é o argumento que justifica limites de consumo que parecem conservadores em operação normal. Para o CEO e para o CIO, é a explicação de por que uma degradação curta em um serviço acessório aparece no relatório mensal como indisponibilidade prolongada do canal de atendimento.

Existe um detalhe de diagnóstico que a cascata torna crítico. O componente que apresenta o pior sintoma quase nunca é o que originou a falha, e a equipe que começa a investigação pelo alerta mais barulhento tende a corrigir um efeito. Por isso a disponibilidade se mede no serviço que o usuário tenta usar, e não no componente que apareceu vermelho no painel.

Por que a causa raiz ficou difícil de identificar

As cinco causas descritas até aqui são antigas. O que mudou foi a facilidade de encontrá-las. Em ambiente monolítico, com poucos servidores e uma equipe só, a inspeção manual chegava à origem em tempo aceitável.

Arquitetura distribuída inverteu a relação entre tamanho do ambiente e tempo de diagnóstico. Uma transação atravessa uma sequência longa de serviços, filas e bancos, e cada salto é uma oportunidade de degradação. Contêineres têm vida curta, então o componente que falhou pode não existir mais quando alguém for procurá-lo. Alerta por limiar fixo, nesse ambiente, produz uma enxurrada de sinais simultâneos que descrevem sintomas do mesmo evento.

A correlação manual desses sinais é o que consome o tempo médio de resolução. Equipes reúnem pessoas de rede, banco, aplicação e infraestrutura na mesma chamada, e cada especialista confirma que o seu domínio está saudável. O incidente segue aberto enquanto ninguém consegue observar a cadeia inteira ao mesmo tempo.

A resposta combina mapa de dependências e inteligência artificial causal. Na plataforma Dynatrace, o OneAgent descobre a topologia da stack sem instrumentação manual serviço a serviço. O Smartscape mantém o mapa de dependências atualizado em tempo real, e o Davis usa esse mapa para apontar o evento gerador da cadeia de falhas. O Grail retém a telemetria em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, e o Dynatrace Query Language, ou DQL, permite consultar o dado bruto quando a investigação precisa ir além do problema apresentado.

A análise causal sobre dados operacionais é a disciplina conhecida como Artificial Intelligence for IT Operations, ou AIOps, que substitui o acúmulo de painéis pela apuração do evento gerador. A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais.

A ordem de implantação importa mais do que a lista de componentes. Cobrir primeiro os serviços que participam da transação de negócio, e a infraestrutura que os sustenta em seguida, produz uma taxonomia de causas utilizável no plantão. O caminho inverso, começar pela infraestrutura porque é a camada mais simples de instrumentar, entrega painel cheio e continua sem responder qual entrega saiu do padrão.

A cobertura precisa alcançar três frentes para que a taxonomia de causas seja verificável no dado. Application Performance Monitoring, ou APM, cobre o comportamento da aplicação e das transações de negócio. A camada de infraestrutura e nuvem cobre consumo de recurso e topologia. Digital Experience Monitoring, ou DEM, mede o que o usuário obteve no navegador ou no aplicativo, e é o dado que separa lentidão percebida de lentidão real.

Para o CIO e para o CTO, a diferença prática está na previsibilidade. Um ambiente em que a causa raiz aparece em minutos permite assumir compromisso de disponibilidade com margem calculada, em vez de margem estimada.

Perguntas frequentes

Uma mesma indisponibilidade pode ter mais de uma dessas causas ao mesmo tempo?

Pode, e a combinação mais frequente junta mudança recente e esgotamento de recurso. A entrega nova passa a reter um pouco mais de memória ou de conexão por requisição. O limite só é alcançado bem depois do deploy, e a relação com a entrega já parece descartada quando o incidente abre. Investigação que para na primeira explicação plausível deixa a segunda causa ativa no ambiente.

Falha de hardware, de rede e de provedor de nuvem entram nessa taxonomia?

Entram, distribuídas entre duas das cinco categorias. Perda de nó, de disco ou de enlace aparece como esgotamento de recurso, porque reduz a capacidade efetiva disponível para a mesma carga. Indisponibilidade de região de nuvem, de resolução de nomes ou de armazenamento gerenciado aparece como dependência externa. Falha física isolada derruba serviço quando a redundância prevista nunca foi exercitada em condição real.

Causa raiz e gatilho são a mesma coisa?

Não, e confundir os dois encerra a investigação cedo demais. Gatilho é o evento que tornou o problema visível, como um pico de acesso ou uma promoção. Causa raiz é a condição que permitiu ao gatilho ter esse efeito, como um limite de conexão dimensionado para a carga média. Remover o gatilho devolve o serviço e mantém a causa raiz intacta para a próxima ocorrência.

Se o serviço volta sozinho, ainda existe causa raiz a procurar?

Existe. Reinício automático, expiração de cache e recuperação do fornecedor devolvem o serviço sem remover a condição que produziu a falha. Intermitência que se resolve sozinha costuma retornar na janela de maior carga, e o processo que falhou pode não existir mais quando alguém for investigar. Telemetria retida do período é a única evidência que sobrevive a esse tipo de incidente.

Essa taxonomia de causas muda em ambiente que ainda é monolítico?

As cinco causas permanecem, o peso entre elas muda. Mudança em produção e esgotamento de recurso pesam mais, porque um único processo concentra memória, threads e conexões de toda a aplicação. Dependência externa e cascata pesam menos, já que existem menos fronteiras de rede para propagar degradação. O diagnóstico é mais curto, e o raio de impacto de cada falha é maior.

Distinguir mudança recente, esgotamento de recurso, dependência externa, erro de configuração e cascata em ambiente distribuído exige telemetria correlacionada e análise causal, não inspeção manual sob pressão. A Rike IS conduz esse trabalho da avaliação inicial à governança de performance continuada sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o histórico de incidentes do seu ambiente para uma conversa técnica com os especialistas da Rike IS.