O que significa um SLA de 99,9% (e o que ele não cobre)

SLA é a sigla para Service Level Agreement, ou Acordo de Nível de Serviço. Trata-se de um contrato (ou de uma cláusula contratual) em que o provedor se compromete formalmente com um patamar mínimo de qualidade para o serviço entregue. No contexto de hospedagem, o indicador mais conhecido é a disponibilidade, popularmente chamada de uptime, que mede a fração do tempo em que a infraestrutura permanece operacional.

Um SLA bem escrito não é apenas uma promessa de marketing. Ele define como a disponibilidade é medida, qual o período de apuração (geralmente mensal), o que conta como indisponibilidade, quais situações ficam de fora e qual a compensação caso a meta não seja cumprida. Sem essas definições, o percentual sozinho diz muito pouco.

Vale separar dois conceitos próximos. O SLA é o compromisso voltado ao cliente, com consequências contratuais. Já o SLO (Service Level Objective, ou Objetivo de Nível de Serviço) é a meta interna que a equipe de operações persegue, normalmente mais rígida que o SLA para criar uma margem de segurança.

O grande problema de comparar SLAs é que a diferença entre 99% e 99,9% parece pequena na escrita, mas é enorme na prática. A forma honesta de avaliar é converter o percentual em tempo de indisponibilidade permitido, o chamado downtime, dentro do período de apuração.

Em valores aproximados: um SLA de 99% admite cerca de 7 horas e 18 minutos de indisponibilidade por mês (algo em torno de 3,65 dias por ano). Um SLA de 99,9% reduz isso para aproximadamente 43 minutos por mês (cerca de 8,77 horas por ano). Já um SLA de 99,99% aperta ainda mais, permitindo por volta de 4 minutos e 23 segundos por mês (perto de 52 minutos por ano).

Cada nove adicional, portanto, corta o tempo tolerado de queda em aproximadamente dez vezes. Por isso a indústria fala em quantidade de noves: 99,9% são os três noves, 99,99% são os quatro noves, e assim por diante. Saber quantos minutos sua operação suporta perder por mês é o ponto de partida para escolher o nível certo, sem pagar por uma resiliência que você não precisa.

Aqui mora a parte que mais gera frustração. Quase todo SLA contém exclusões, ou seja, períodos de indisponibilidade que não contam contra a meta. Reconhecer essas exclusões é tão importante quanto o percentual em si, porque elas determinam o que o número realmente cobre.

As exclusões mais comuns são quatro. A manutenção programada, desde que comunicada com antecedência dentro de janelas previstas, costuma não ser contabilizada. Os casos de força maior, como desastres naturais, falhas em larga escala de operadoras de telecomunicações e eventos fora do controle do provedor, também ficam de fora. Erros do próprio cliente, como uma configuração equivocada, um deploy quebrado ou o esgotamento de recursos contratados, não são responsabilidade do provedor. E ataques originados por terceiros, como DDoS (Distributed Denial of Service, ou negação de serviço distribuída), frequentemente entram nas exclusões, ainda que muitos provedores ofereçam mitigação como serviço.

Nenhuma dessas exclusões é necessariamente abusiva; elas existem porque o provedor não pode garantir aquilo que está fora do seu alcance. O ponto de atenção é o equilíbrio: janelas de manutenção excessivamente amplas ou uma definição vaga de força maior podem esvaziar o valor prático do SLA.

Quando o provedor descumpre a meta, a compensação típica não é um reembolso em dinheiro, mas um crédito de serviço (service credit): um abatimento percentual na fatura do período seguinte, proporcional ao tamanho da falha. Quanto maior a indisponibilidade, maior o crédito, geralmente organizado em faixas.

É fundamental entender três limitações comuns desse mecanismo. Primeiro, o crédito quase sempre tem teto, normalmente limitado a uma fração do valor mensal do serviço, e raramente cobre o prejuízo real do seu negócio durante a queda. Segundo, o crédito costuma ser a única e exclusiva reparação prevista, afastando outras formas de indenização. Terceiro, em muitos contratos o cliente precisa solicitar o crédito ativamente, dentro de um prazo, anexando evidências; ele não é aplicado de forma automática.

Por isso, encare o crédito de serviço como um incentivo para que o provedor mantenha a qualidade, e não como um seguro contra perdas. Se o seu negócio sofre danos relevantes a cada minuto offline, a proteção real vem da arquitetura e do planejamento, não da cláusula de crédito.

Este é o mal-entendido mais caro. O SLA do provedor cobre a infraestrutura que ele controla: energia, refrigeração, rede, conectividade e, dependendo do plano, a disponibilidade da máquina virtual ou do servidor. Ele não cobre o que roda em cima disso. Se a sua aplicação cai por um bug, um banco de dados sobrecarregado ou um certificado TLS expirado, o servidor continuou no ar e o SLA foi cumprido, mesmo com seu site fora.

A disponibilidade que o usuário final percebe é o resultado da combinação de todas as camadas: infraestrutura, sistema operacional, runtime, banco de dados, código da aplicação e dependências externas, como gateways de pagamento e APIs de terceiros. Como esses elementos se multiplicam, a disponibilidade efetiva tende a ser menor que a do componente mais frágil da cadeia.

Construir resiliência na sua stack significa eliminar pontos únicos de falha. Na prática, isso inclui redundância de instâncias, balanceamento de carga, réplicas e backups testados do banco de dados, monitoramento com alertas, health checks automáticos e um plano de recuperação ensaiado. O SLA do provedor é a fundação sólida sobre a qual você constrói; a casa, no entanto, é sua responsabilidade.

Antes de assinar, vá direto às definições. Verifique como a indisponibilidade é medida: a partir de quanto tempo de queda começa a contar, com que frequência o monitoramento é feito e de quais pontos de observação. Um SLA que só considera quedas acima de cinco minutos contínuos é bem diferente de um que conta cada segundo.

Em seguida, examine o período de apuração e as janelas de manutenção. Metas calculadas sobre um ano inteiro diluem incidentes que seriam graves em uma medição mensal. Janelas de manutenção muito largas ou sem limite de frequência podem, na prática, transformar horas de indisponibilidade planejada em tempo que simplesmente não conta.

Por fim, leia com atenção a lista de exclusões, a tabela de créditos, o prazo e o procedimento para solicitá-los, e a cláusula de reparação exclusiva. Pergunte ao provedor o que acontece em cenários concretos do seu negócio. Um fornecedor confiável responde com clareza e transparência; respostas evasivas são, por si só, um sinal de alerta.

Um SLA de 99,9% é um excelente padrão para a maioria das aplicações de produção: ele permite cerca de 43 minutos de indisponibilidade por mês e equilibra confiabilidade com custo. Mas o número só faz sentido quando você entende como é medido, o que está excluído e como funcionam os créditos. Comece sempre traduzindo o percentual em minutos e confrontando esse limite com o que sua operação realmente tolera.

Lembre-se de que o SLA cobre a infraestrutura, não o seu código. Por mais sólido que seja o compromisso do provedor, a disponibilidade percebida pelo usuário depende de uma stack resiliente, com redundância, monitoramento e backups testados. Trate o SLA como base, e a arquitetura como a sua linha de frente.

A Heffer oferece SLA de 99,9% sustentado por um datacenter Tier III em São Paulo, storage 100% NVMe, suporte 24/7 e migração gratuita, com termos descritos de forma clara para que você saiba exatamente o que está contratando. Mais do que um número bonito, o que importa é um compromisso transparente sobre o qual você pode construir com segurança.