As falhas de sistema são sempre fixáveis? O que a prática mostra

Nem toda falha de sistema é corrigível no prazo que o negócio exige. Correção elimina a causa, mitigação reduz o efeito e contorno preserva o serviço por outro caminho, com custos e prazos distintos. O que separa risco aceito de risco ignorado é o registro com dono, prazo de revisão e efeito medido, sustentado por observabilidade contínua.

Parte das falhas se elimina na origem. Parte se reduz a um efeito tolerável, sem desaparecer. E parte permanece exatamente onde está, porque o custo de removê-la supera o custo de conviver com ela sob controle. Essa é a resposta honesta à pergunta.

A distinção que organiza o assunto tem três termos: correção, mitigação e contorno. Confundir os três produz relatório de incidente que promete o que a engenharia não vai entregar.

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.

Correção, mitigação e contorno

Toda falha admite três respostas possíveis, e cada uma tem um custo próprio. Correção elimina a causa raiz. Mitigação reduz o efeito sem remover a causa. Contorno preserva o serviço por um caminho alternativo, deixando a causa intacta e o caminho original quebrado.

Correção é a resposta cara. Ela exige entender o mecanismo que produziu a falha, alterar o componente responsável, validar a alteração e colocá-la em produção sem introduzir regressão. Em sistema crítico com janela de mudança restrita, esse percurso leva semanas.

Mitigação atua no efeito. Um limite de requisições por cliente não corrige a consulta lenta que satura o banco de dados, mas impede que uma única origem consuma toda a capacidade disponível. A causa continua ali, medida e conhecida, com o impacto reduzido a um nível que o compromisso de serviço tolera.

Contorno é a resposta de menor prazo e maior risco acumulado. Redirecionar tráfego para uma rota secundária, desativar uma funcionalidade específica ou processar em lote o que deveria correr em tempo real resolve a noite de plantão e cria uma pendência que ninguém registrou.

A diferença entre as três aparece no relatório do incidente. Um chamado encerrado com contorno e classificado como corrigido volta a abrir, e volta sem que ninguém espere. A equipe seguinte recebe um histórico que afirma resolução onde houve adiamento, e perde tempo procurando causa nova para um efeito antigo.

Para o Site Reliability Engineer, ou SRE, a distinção governa o orçamento de erro, a margem de indisponibilidade tolerada derivada do objetivo de disponibilidade acordado. Contorno consome orçamento futuro, porque a falha vai voltar. Para o CIO, a mesma distinção é previsibilidade: um portfólio cheio de contornos não anunciados produz surpresa orçamentária no trimestre seguinte.

Três perguntas separam as respostas na prática, e precisam ser feitas antes de encerrar o chamado. A causa foi removida ou apenas contida? O efeito residual está medido? Existe data marcada para revisitar a decisão?

Quando o limite é arquitetural

Existe uma classe de falha que nenhuma correção pontual resolve, porque o defeito está na decisão de desenho e não em uma linha de código. Limite arquitetural é isso: o comportamento indesejado decorre da estrutura escolhida, e removê-lo significa mudar a estrutura.

Três exemplos tornam o conceito concreto. O primeiro é o banco de dados compartilhado por serviços que deveriam ser independentes, em que cada serviço herda a indisponibilidade dos outros e nenhum ajuste de consulta desfaz o acoplamento. O segundo é o processamento síncrono em cadeia longa, no qual a latência de um componente distante se propaga até o usuário. O terceiro é o estado guardado na memória da aplicação, que impede substituir uma instância sem perder sessão.

Nos três casos, a correção existe e tem nome: separar o dado, tornar o fluxo assíncrono, externalizar o estado. Todas exigem reescrita, migração de dados e um período de convivência entre desenho antigo e desenho novo. Nenhuma cabe em uma janela de manutenção.

Enquanto a reescrita não acontece, resta trabalhar no efeito. Isolar consumidores por cota, impor tempo limite a cada chamada remota, cortar a cadeia com um mecanismo de interrupção que falha rápido em vez de esperar, e replicar leitura para tirar carga do caminho crítico.

Para o gerente de infraestrutura, limite arquitetural aparece como custo que sobe sem retorno proporcional: mais máquina no mesmo desenho compra tempo, não estabilidade. Para o profissional de DevOps, aparece como implantação que exige parada, porque o desenho não tolera duas versões em produção ao mesmo tempo.

A plataforma Dynatrace torna o limite arquitetural visível e quantificado. O Smartscape, mapa de dependências em tempo real, expõe quem depende de quem, e o rastreamento distribuído mostra em qual salto a latência nasce. O trace é o GPS de uma viagem, mostrando cada parada do trajeto e quanto tempo o pedido ficou em cada uma. Com esses dois, a conversa sobre reescrever deixa de ser opinião de arquiteto e passa a ter número de impacto anexado.

Sistemas legados: o que ainda dá para observar

Sistema legado é o que sustenta operação e não aceita as práticas atuais de instrumentação. Aparece em folha de pagamento, em processamento de retaguarda bancária, em cadastro de órgão público. Roda há anos, raramente tem alguém que o conheça por inteiro, e continua sendo o caminho por onde o dinheiro passa.

Tratar o legado como zona cega quase nunca corresponde ao ambiente real. Mesmo quando o código não pode ser alterado, três camadas continuam observáveis: o comportamento do processo no sistema operacional, o tráfego que entra e sai do componente, e o resultado da transação de negócio no ponto em que ela termina. Nenhuma delas depende de alterar a aplicação.

Instrumentação são as câmeras instaladas na fábrica, e o setor sem câmera é o setor sobre o qual nada pode ser explicado depois.

O OneAgent, agente unificado que descobre a stack sem configuração manual por componente, cobre boa parte dessa camada externa sem exigir mudança no código legado. Onde o agente não alcança, o OpenTelemetry, padrão aberto e vendor-neutral da CNCF para gerar telemetria, entra pela borda: instrumenta o serviço moderno que chama o antigo e registra tempo, volume e resultado de cada chamada. OpenTelemetry funciona como o padrão USB-C da telemetria.

Para o CTO, isso muda a natureza da decisão sobre o legado. Substituir um sistema sem dado de comportamento é aposta. Substituir com dado de volume, latência e taxa de erro por transação é projeto com escopo definido e custo estimável.

Existe um ganho intermediário que quase nunca entra no planejamento. Observar o legado por fora costuma revelar que apenas uma fração das funcionalidades é usada de fato, e essa informação reduz o escopo da eventual substituição antes de qualquer linha ser escrita.

Dívida técnica como decisão consciente

Dívida técnica é o custo futuro de uma escolha feita para ganhar prazo no presente. O termo carrega a metáfora financeira por inteiro: existe principal, existe juro, e o juro aparece em cada alteração que precisa contornar a escolha antiga.

Contrair dívida faz parte da gestão normal de engenharia. Toda entrega dentro de prazo curto contrai alguma, e uma equipe que nunca contrai dívida entrega devagar demais para o negócio que serve. O defeito é a dívida não registrada.

Risco residual é o nome do que sobra depois de aplicada a mitigação possível. Aceitar risco residual é decisão legítima, com uma condição: a decisão precisa ter dono, prazo de revisão e efeito conhecido. Sem esses três elementos, aceitação e omissão produzem exatamente o mesmo documento.

Um registro de risco residual útil responde a quatro perguntas. Qual falha permanece possível. Que impacto ela produz se acontecer. Que mitigação está ativa e o que ela deixa descoberto. Quem revisa a decisão e em que data.

Para o CEO, esse registro converte incerteza em item de risco comparável com os demais riscos do negócio. Para o gerente de infraestrutura, ele sustenta orçamento: um risco documentado com impacto estimado defende pedido de investimento melhor do que uma percepção difusa de fragilidade.

Há uma diferença de comportamento entre as duas situações que aparece no incidente. Equipe que trabalha com dívida registrada reconhece o sintoma em minutos, porque alguém já escreveu que aquilo podia acontecer. Equipe que trabalha com dívida esquecida investiga do zero, sob pressão, com o serviço fora do ar.

Mapear o que a operação já aceita conviver exige inventário honesto do ambiente e critério para medir impacto. A Rike IS conduz esse levantamento junto às equipes de operações e de engenharia, transformando percepção difusa em lista priorizada.

Como priorizar o que não vai ser corrigido

Nenhuma equipe corrige tudo, e priorizar é a atividade real por trás da promessa de qualidade.

Três variáveis ordenam a fila, e a ordem entre elas importa. Impacto por ocorrência. Frequência esperada. Custo de conviver, que soma as mitigações ativas, o contorno operacional e o tempo de plantão consumido a cada repetição.

Impacto isolado engana. Uma falha de impacto alto e ocorrência rara pode custar menos que uma falha de impacto médio que se repete toda semana e consome boa parte de um turno de equipe a cada vez. A conta que importa multiplica impacto por frequência e soma o custo de convivência.

O orçamento de erro entra aqui como instrumento de decisão, não como métrica de relatório. Enquanto o orçamento do período está preservado, a fila de correção segue a ordem de valor para o negócio. Quando o orçamento se esgota, a correção da falha que mais o consome passa à frente, sem negociação.

Para o DevOps, esse critério muda a esteira de entrega: correção de disponibilidade entra como item de trabalho com a mesma prioridade de funcionalidade nova, e não como tarefa de manutenção sem dono. Para o SRE, ele encerra a discussão sobre o que merece acionamento noturno, porque a fila já está ordenada quando o alerta chega.

Existe uma quarta variável que aparece tarde nos inventários: o custo de detectar. Uma falha percebida pela operação em minutos custa uma fração do que custa a mesma falha percebida por reclamação de usuário, e essa diferença é o que faz a redução do tempo de inatividade depender tanto de detecção quanto de correção.

A fila também precisa de critério de saída. Um item sai por correção, por eliminação do componente que o produz, ou por mudança do contexto que o tornava relevante. Nunca por esquecimento no fim da lista.

O papel da observabilidade no que não se corrige

Observabilidade encurta o intervalo entre a falha começar e alguém saber, com precisão suficiente para agir sem investigar do zero.

Em ambiente que convive com dívida técnica declarada, essa redução vale mais do que em ambiente novo. Falha conhecida e não corrigida tem assinatura previsível: a mesma fila que cresce, o mesmo processo que consome memória, a mesma dependência que responde devagar sob carga. Reconhecer a assinatura de imediato é o que separa um incidente resolvido em minutos de um incidente que atravessa o turno.

Três disciplinas se combinam nesse ponto. Application Performance Monitoring, ou APM, mostra onde o tempo é gasto dentro do código. Digital Experience Monitoring, ou DEM, mostra o que o usuário obteve de fato no dispositivo dele. Artificial Intelligence for IT Operations, ou AIOps, ordena o volume de sinais e aponta a causa raiz.

O Davis, que dentro do Dynatrace Intelligence é responsável pela análise causal da plataforma Dynatrace, opera sobre o mapa de dependências e aponta o evento gerador de uma cadeia de sintomas. Em ambiente com contorno ativo, essa capacidade separa o sintoma esperado do sintoma novo. 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.

Três capacidades sustentam a convivência com o que não se corrige.

A primeira é a detecção por desvio de comportamento, que percebe a degradação antes de qualquer limiar absoluto ser rompido. A segunda é a correlação entre camadas, que liga o sintoma visto pelo usuário ao componente que o produziu e poupa a rodada de suspeita entre equipes. A terceira é a retenção de contexto, que preserva o estado do ambiente no instante do incidente, mesmo quando a mitigação apagou a evidência ao reiniciar o componente.

O Grail sustenta essa retenção, guardando logs, métricas, traces e eventos em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, e com consulta rápida sobre todo o histórico. O Dynatrace Query Language, ou DQL, é como a equipe interroga esse acervo depois. Perguntar quantas vezes a falha conhecida ocorreu no trimestre, e quanto tempo de equipe ela consumiu, deixa de ser estimativa e passa a ser consulta.

Para o SRE em plantão, essa combinação encurta o tempo médio de resolução de um item que ele já sabe que vai voltar. Para o CIO, ela transforma a dívida aceita em série histórica, e série histórica é o que sustenta a decisão de investir na correção definitiva.

Perguntas frequentes

Quem assina a aceitação de um risco residual: a área técnica ou o negócio?

Quem responde pelo serviço afetado, não quem descobriu a falha. A área técnica descreve o efeito e o custo de remover, e a decisão de conviver pertence a quem responde pelo resultado do serviço diante do cliente. Registro assinado por engenheiro isolado desmonta no primeiro incidente, porque ninguém no nível de decisão reconhece a escolha como sua.

Dívida técnica e limite arquitetural são a mesma coisa?

Não, e confundir os dois distorce o planejamento. Dívida técnica nasce de uma escolha deliberada por prazo e costuma ter caminho de saída conhecido. Limite arquitetural é propriedade do desenho vigente, muitas vezes correto quando foi tomado, e o caminho de saída é outra arquitetura. Dívida se paga por partes, e limite arquitetural se resolve por substituição.

Um contorno pode virar solução definitiva?

Pode, desde que a promoção seja explícita. Existe contorno que, sob observação prolongada, se mostra estável, barato e sem efeito colateral relevante. Nesse caso cabe reconhecê-lo como desenho aceito, documentá-lo como tal e retirá-lo da fila de correção. O que não vale é a promoção silenciosa, em que o provisório vira permanente porque ninguém revisitou o chamado.

E quando o fornecedor do sistema legado não autoriza instalar agente no servidor?

A camada externa continua disponível, e ela responde à maior parte das perguntas de operação. Tráfego de entrada e de saída, tempo de resposta observado por quem chama e resultado da transação no ponto de conclusão não exigem tocar no ambiente contratado. A restrição contratual limita a profundidade do diagnóstico dentro do componente, não a medição do que ele entrega.

Vale corrigir uma falha conhecida que nunca chega a consumir o orçamento de erro?

Raramente, e a resposta muda quando o custo de convivência é contabilizado. Falha que não pressiona o objetivo de disponibilidade ainda consome atenção de plantão, gera chamado repetido e trava alteração vizinha no mesmo componente. A decisão merece revisão quando esse desgaste operacional passa a pesar mais do que o esforço de eliminar a causa raiz.

Conviver com falha que não será corrigida no curto prazo exige inventário honesto, critério de priorização e visibilidade contínua do que foi aceito. A Rike IS trabalha nas três frentes sobre a plataforma Dynatrace: a implantação instrumenta o ambiente, a leitura ordena a fila de convivência e a governança de performance revisa cada risco aceito no prazo combinado, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o inventário do seu ambiente para uma conversa técnica com os especialistas da Rike IS.