Quando Lento Conta Como Parado: o Objectivo de Nível de Serviço para a Latência

O painel mostra 100% de disponibilidade. A verificação de saúde responde em ordem. Nenhum alerta disparou durante a manhã. E, no entanto, cada pedido de pagamento demora vários segundos, parte dos utilizadores desiste a meio, e a equipa de apoio começa a receber queixas antes de a equipa técnica perceber que há um problema.

Para quem usa o serviço, isto é uma falha. Para a monitorização desenhada à volta de "está no ar ou não está", não aconteceu nada.

O que diz a prática em 2026

O relatório reúne 418 respostas de profissionais de vários sectores, dimensões e geografias. O número mede percepção de gravidade, não impacto medido, mas a percepção já é suficiente para mudar uma decisão: se dois terços de quem opera sistemas põe a lentidão ao nível da paragem, a gestão de fiabilidade que só mede a paragem está a deixar de fora metade do problema.

SLI e SLO, em linguagem simples

A engenharia de fiabilidade de sistemas (SRE) organiza este tema com dois conceitos.

Um indicador de nível de serviço (SLI) é uma medida quantitativa, definida com cuidado, de um aspecto do serviço prestado. A latência de um pedido, a proporção de pedidos com erro ou a disponibilidade são indicadores.

Um objectivo de nível de serviço (SLO) é o valor alvo, ou o intervalo de valores, para esse indicador. "95% dos pedidos de pagamento respondem em menos de 800 milissegundos, medidos ao longo de 30 dias" é um objectivo. O número concreto é um exemplo e não uma recomendação: o limiar certo depende da jornada e de quem a usa.

O capítulo sobre objectivos de nível de serviço do livro de SRE da Google aponta a latência dos pedidos como um dos indicadores que a maioria dos serviços considera. Na prática, muitas operações têm objectivo de disponibilidade e nenhum de latência. É aí que a degradação passa despercebida.

Porque a média engana

A tentação é medir a latência média. O problema é que a média esconde precisamente o que interessa.

Um serviço pode ter uma média confortável e, ao mesmo tempo, um em cada vinte pedidos a demorar dez vezes mais. Esses pedidos lentos nem sempre são aleatórios: podem concentrar-se nas horas de maior carga, nos utilizadores com mais dados ou nas operações mais pesadas, que muitas vezes são as de maior valor.

Os percentis resolvem isto. Medir o percentil 95 ou o percentil 99 mostra a forma da distribuição e revela a cauda lenta, onde está o utilizador insatisfeito. O mesmo capítulo do livro de SRE da Google defende exactamente esta escolha: os percentis permitem ver o que a média apaga.

Um objectivo por jornada crítica, e não um objectivo global para todo o serviço, é o passo seguinte. Consultar um saldo e submeter um pagamento não têm a mesma tolerância à espera.

Medir de onde o utilizador está

Um detalhe de medição muda o resultado. A latência medida no servidor não inclui a rede, a região nem o caminho que o pedido percorre até lá chegar. Um serviço pode responder depressa dentro do centro de dados e chegar lento a quem está do outro lado.

O relatório da Catchpoint insiste neste ponto: sem monitorização a partir de onde os utilizadores realmente estão, a visão da fiabilidade fica incompleta. Para um objectivo de latência, isso significa escolher o ponto de medição com a mesma atenção com que se escolhe o limiar.

Quando a latência gasta o orçamento de erro

Um objectivo de nível de serviço cria, por definição, um orçamento de erro: a margem de falha que o objectivo aceita. Se o alvo é 95% dos pedidos abaixo do limiar, os restantes 5% são o orçamento.

A decisão que separa uma operação madura de uma operação apenas monitorizada é esta: quando a latência consome o orçamento de erro, o caso é tratado como uma indisponibilidade. O mesmo caminho de alerta, o mesmo responsável, a mesma revisão depois do incidente.

Falta ainda ligar o objectivo ao negócio. No mesmo relatório, só 26% dos profissionais avaliam directamente se as melhorias de desempenho afectam métricas de negócio como a receita ou a satisfação do cliente. Um objectivo de latência sem essa ligação protege o serviço, mas não consegue defender o investimento que exige. É a mesma lógica que já aparece nas métricas DORA de estabilidade da entrega: o que não se mede em termos de negócio acaba por perder a discussão do orçamento.

Cinco perguntas antes de declarar um serviço fiável

• As jornadas críticas do serviço estão identificadas e nomeadas?
• Cada jornada crítica tem um indicador de latência definido, além da disponibilidade?
• O objectivo está expresso num percentil, e não numa média?
• A latência é medida a partir de onde os utilizadores estão, ou só a partir do servidor?
• Existe um responsável nomeado que actua quando a latência consome o orçamento de erro?

Conclusão

Fiabilidade não é apenas estar no ar. É estar suficientemente rápido para ser usado. Enquanto a latência não tiver um objectivo próprio, com percentil, ponto de medição e responsável, a degradação continua a ser a falha que a operação não vê e que o utilizador vê sempre.

Para definir estes objectivos nas jornadas críticas, com capacidade sénior que reforça a equipa interna, como descrito na comparação entre SRE como serviço e equipa interna, é possível agendar uma Sessão de Esclarecimento, sem compromisso.