Por que 99,9% de uptime não é o que parece — e como calcular o que realmente importa

Dois fornecedores de SaaS chegam para você. Ambos anunciam 99,9% de uptime. Aparentemente equivalentes.

Fornecedor A: 100% dos seus incidentes são micro-interrupções de 10-30 segundos espalhadas ao longo do mês. Total mensal de downtime: 43 minutos. Cliente final raramente nota.

Fornecedor B: 1 grande incidente de 43 minutos por mês. Geralmente em horário de pico. Cliente nota severamente.

Mesmo SLA. Realidades completamente diferentes para a operação.

99,9% de uptime não é número único. É range que esconde realidades muito diferentes. Vou te mostrar como entender o que está por baixo.

O número que todo fornecedor anuncia e o que ele esconde

99,9% no marketing do fornecedor é o número agregado. Soma todas as horas indisponíveis e divide pelo total de horas no período.

Esse número não te diz:

• Quando os incidentes acontecem (horário de pico ou madrugada)
• Por quanto tempo cada incidente dura
• Quantos incidentes existem (10 incidentes de 4 min ou 1 incidente de 43 min)
• Como os incidentes se concentram ao longo do trimestre
• Qual a distribuição entre os módulos do sistema (talvez 1 módulo crítico tenha disponibilidade muito pior que a média)

Tudo isso fica abstraído no número único.

Quando você compra com base em "99,9%", você compra uma média. Médias escondem extremos. Extremos são onde mora o problema operacional.

Uptime mensal vs anual: a diferença que o SLA não conta

Vamos comparar duas formulações:

SLA mensal de 99,9%: em qualquer mês individual, o uptime tem que ser pelo menos 99,9%. Se um mês ficar abaixo, viola SLA.

SLA anual de 99,9%: no acumulado de 12 meses, o uptime tem que ser pelo menos 99,9%. Você pode ter um mês ruim, desde que compensado por meses bons.

Diferença prática:

SLA anual de 99,9% permite que um mês tenha até 8,7 horas de downtime, desde que os outros 11 meses sejam perfeitos.

SLA mensal de 99,9% limita cada mês individual a no máximo 43 minutos.

Para empresa onde o negócio é sazonal, com fechamento mensal crítico, SLA anual é praticamente fictício. Você pode ter o mês de fechamento todo comprometido e o fornecedor continuar dentro do SLA.

Negocie sempre SLA mensal, não anual. Idealmente com penalidade incremental por mês violado.

Sistemas críticos vs sistemas de suporte: SLA diferente para cada

Outro erro comum: tratar todos os sistemas com mesmo SLA.

ERP, CRM, sistema de prontuário médico, sistema de gestão de produção — são sistemas críticos. Indisponibilidade tem impacto direto no negócio.

Portal de RH, intranet, sistema de viagens — são sistemas de suporte. Indisponibilidade incomoda mas não para a operação.

Faz sentido pagar 99,99% para todos? Não.

O que faço com clientes:

1. Categorizo os sistemas em 3 ou 4 níveis de criticidade
2. Para cada nível, defino SLA apropriado:
   • Tier 1 (crítico): 99,99% mensal, RTO 2h, RPO 15min
   • Tier 2 (importante): 99,9% mensal, RTO 4h, RPO 1h
   • Tier 3 (suporte): 99,5% mensal, RTO 24h, RPO 24h
   • Tier 4 (não-crítico): best effort
3. Negocio contrato e infraestrutura de acordo com a categoria

Resultado: economia significativa em sistemas de menor criticidade e investimento concentrado onde realmente importa.

O que medir além do uptime (e que o fornecedor prefere que você não meça)

Uptime é uma métrica. Há outras que importam tanto ou mais e que raramente são negociadas:

Performance (tempo de resposta)

Sistema disponível mas lento é praticamente igual a sistema indisponível. Negocie tempo de resposta para transações críticas. Por exemplo: p95 < 2 segundos para 95% das transações, p99 < 5 segundos.

Throughput (capacidade)

Garantia de suportar X transações por segundo ou Y usuários simultâneos. Sem essa garantia, o sistema pode degradar em horário de pico mesmo sem ficar indisponível.

Taxa de erro

Quantas transações dão erro em condições normais? Negocie limite máximo (0,1% é razoável para transações críticas).

RPO (Recovery Point Objective)

Em caso de incidente grave, quanto de dado pode ser perdido? Para sistemas transacionais, RPO < 5 min é desejável. RPO de 24h é inaceitável para a maioria dos sistemas críticos.

RTO (Recovery Time Objective)

Em caso de desastre, em quanto tempo o sistema deve estar de volta? Para sistemas críticos, RTO < 4h. Para sistemas de suporte, pode ser 24h ou mais.

Um SLA com 5-7 métricas é defensável. Um SLA com 1 métrica é decorativo.

Como auditar o SLA que você está pagando

Última pergunta: você está realmente recebendo o SLA contratado?

Cliente típico não tem como medir. Confia no relatório do fornecedor. Esse relatório tem três problemas estruturais:

Primeiro, o fornecedor mede ele mesmo o serviço dele. Há conflito de interesse.

Segundo, a metodologia de medição é definida pelo fornecedor. Eles definem o que conta como "downtime" e o que não conta.

Terceiro, o relatório é apresentado de forma agregada, sem detalhe de incidentes individuais.

O que faço com clientes para auditar:

1. Monitoramento independente

Ferramenta externa (como Pingdom, UptimeRobot, ou solução customizada) que monitora o sistema de forma independente do fornecedor. Comparo o relatório do fornecedor com a medição independente.

Em vários casos identifiquei discrepâncias de 0,3% a 1,2% entre o reportado e o medido. Em sistemas com SLA apertado, isso é diferença material.

2. Direito contratual de auditar logs

Cláusula que permite, em caso de divergência, acessar os logs detalhados do fornecedor com acompanhamento de auditor independente.

3. Métricas operacionais internas

Quantos chamados internos foram abertos relacionados a indisponibilidade ou lentidão. Esse número deveria ter correlação clara com o SLA reportado. Se o SLA reportado é 99,99% mas você tem 80 chamados de "sistema lento" por mês, algo não bate.

4. Revisão trimestral formal

Reunião trimestral com fornecedor para revisar SLA, com auditoria contraposta. Cria pressão para o fornecedor manter qualidade da medição.

SLA não auditado é SLA não cumprido. O fornecedor reporta o que quer. Você descobre o que aconteceu de verdade quando precisa acionar a penalidade — e geralmente tarde demais.

Padrões temporais de incidente: o que olhar

Dois sistemas com mesmo SLA podem ter padrões temporais muito diferentes:

• Concentração em horário comercial vs noturno
• Concentração em dias específicos (sextas, fechamentos)
• Concentração em períodos do ano (alta demanda)
• Distribuição entre módulos do sistema

Solicite ao fornecedor histórico de 12 meses de incidentes detalhados antes de assinar. Sem esse histórico, você compra cegamente.

Fornecedor sério tem esses dados e compartilha. Fornecedor que se recusa a compartilhar está te dizendo algo sem palavras.

SLA composto: quando o sistema depende de múltiplos serviços

Empresas modernas operam ecossistemas com múltiplos fornecedores. Cloud para infraestrutura, SaaS para CRM, SaaS para ERP, integradores no meio.

Cada fornecedor tem seu SLA. Mas o SLA real para o usuário é a multiplicação:

Cloud 99,9% × CRM 99,9% × ERP 99,5% × Integrador 99,9% = 99,2% efetivo (5,8 horas de downtime/mês potencial).

Esse cálculo precisa estar feito. Não basta olhar SLA individual de cada componente. O SLA real para o negócio é composto.

Para melhorar SLA composto, há duas opções: reduzir número de dependências (consolidar fornecedores) ou aumentar SLA individual de cada componente.

SLA em SaaS multi-tenant: o problema oculto

SaaS multi-tenant significa que vários clientes compartilham mesma instância da aplicação.

Isso tem implicações no SLA real:

• Incidente que afeta um tenant geralmente afeta todos
• Otimizações que beneficiam um cliente são compartilhadas
• Mas degradação por uso intensivo de outro cliente pode te afetar

Negocie em SaaS multi-tenant:

• Garantias de isolamento de performance ("noisy neighbor" não pode te afetar)
• Direito de migrar para instância dedicada se necessário
• Transparência sobre uso de recursos compartilhados

SaaS dedicado custa mais mas elimina classe inteira de problemas. Para sistemas verdadeiramente críticos, vale considerar.

Em resumo: como avaliar SLA além do número

1. Solicite histórico detalhado de 12 meses de incidentes antes de contratar
2. Analise padrões temporais (concentração em horário comercial, dias específicos)
3. Diferencie SLA mensal de SLA anual — mensal protege mais
4. Categorize sistemas em tiers de criticidade com SLAs diferentes
5. Calcule SLA composto quando há múltiplos fornecedores em cadeia
6. Considere SaaS dedicado vs multi-tenant para sistemas verdadeiramente críticos

O número anunciado pelo fornecedor é só o ponto de partida. O SLA real depende de fatores que precisam ser explicitamente investigados antes da assinatura.

Auditoria periódica de SLA: o ritmo certo

Contrato assinado, SLA negociado. Trabalho terminou? Não. Trabalho está começando.

Auditoria periódica recomendada:

• Mensal: revisão do relatório do fornecedor vs medição independente
• Trimestral: reunião formal de SLA com fornecedor
• Semestral: análise de tendências de longo prazo
• Anual: revisão completa do contrato e renegociação se necessário

Sem essa cadência, o SLA contratado vira teoria. Fornecedor relaxa, reporta com criatividade, e a próxima crise pega o cliente sem defesas estruturadas.

Cliente que mantém cadência de auditoria recebe SLA real. Cliente que assina e esquece recebe SLA de papel.

SLA em ambientes híbridos: complexidade adicional

Empresa típica hoje opera ambientes híbridos: parte on-premise, parte cloud, parte SaaS. Cada componente com SLA próprio.

O SLA real para o usuário é determinado pelo componente mais fraco da cadeia.

Se a aplicação web está em cloud com SLA 99,99%, mas o banco de dados está em servidor on-premise com SLA 99,5% (calculado pela equipe interna), o SLA composto é 99,5%.

Em ambientes híbridos, mapeie todos os componentes, calcule SLA individual, e identifique gargalo. Investir em melhorar o componente mais robusto não muda nada. Investir no gargalo melhora SLA total.

Antes de qualquer renovação de contrato, vale rodar a calculadora. Não só para conhecer custo de downtime, mas para validar se o SLA atual está calibrado para a criticidade real do seu negócio.

A matemática que poucos fazem

Quando o fornecedor diz "uptime de 99,9%", soa robusto. Faz a conta com cuidado e o cenário muda.

99,9% mensal = 43,8 minutos de indisponibilidade permitida por mês = 8,8 horas por ano. Para sistema crítico que processa centenas de milhares de transações por dia, 43,8 minutos podem representar milhões em transações perdidas.

99,99% mensal = 4,4 minutos por mês = 52,6 minutos por ano. Diferença massiva no impacto operacional.

99,999% (os famosos "cinco noves") = 25 segundos por mês = 5,3 minutos por ano. Esse nível raramente é oferecido em contrato comum — exige infraestrutura redundante substancial.

Empresa que aceita 99,9% sem fazer essa conta está aceitando indisponibilidade significativa. Vale calcular o impacto financeiro de cada nível em transações reais, e decidir o que o negócio realmente tolera. Frequentemente a empresa descobre que precisa de 99,95% ou 99,99% — não 99,9% — e renegocia o contrato com argumento técnico sólido.

O custo real da indisponibilidade por hora

Outra conta que poucos fazem antes da negociação: quanto custa uma hora de indisponibilidade do sistema crítico em questão?

Componentes do custo: receita perdida (transações que não acontecem); perda de produtividade (funcionários parados ou em workaround); custos de recuperação (equipe extra mobilizada, comunicação a clientes); impacto reputacional (clientes insatisfeitos, churn); multas e penalidades (clientes B2B com SLA contra a empresa).

Para empresa de médio porte de varejo digital, custo típico por hora de indisponibilidade do core: R$ 80-250 mil. Para banco digital, R$ 500 mil a R$ 2 milhões. Para SaaS B2B, R$ 100-500 mil + impacto reputacional substancial.

Conhecer esse número permite decisão racional. Vale a pena pagar R$ 200 mil/mês a mais por SLA superior se isso reduz expectativa de indisponibilidade em 5 horas/ano? Se o custo por hora é R$ 250 mil, evitar 5 horas vale R$ 1,25 milhão. Conta óbvia.

O conceito de "uptime composto"

Em ambientes modernos, raramente um sistema crítico depende de uma única peça. Tipicamente depende de cadeia de serviços — frontend, backend, banco, cache, autenticação, integrações, CDN. Cada componente tem seu próprio SLA.

Aqui acontece efeito cumulativo que ninguém antecipa: uptime composto é menor que uptime de cada componente. Se você tem 5 componentes em série, cada com 99,9% de uptime, o uptime composto é aproximadamente 99,5% — significativamente pior.

A matemática simplificada: uptime composto = uptime_a × uptime_b × ... × uptime_n. Para 5 componentes a 99,9%: 0,999^5 ≈ 0,995, ou 99,5%. Para 10 componentes nas mesmas condições: ≈ 99%.

Implicação prática: o SLA de cada componente individual precisa ser melhor do que o SLA-meta do serviço completo. Empresa que aceita 99,9% em cada componente fica com sistema integral abaixo de 99,5%. Quando o SLA-meta do serviço é 99,9%, cada componente precisa estar acima de 99,98% — ou a arquitetura precisa de redundância para compensar.

Esse conceito muda o desenho de arquitetura, decisão de fornecedores, e estrutura de contratos. Empresa que não considera, paga várias vezes a indisponibilidade real.