Uptime e SLA: a matemática dos noves (99,9% vs 99,99%)
99,99% soa redondo, mas significa que sua loja pode cair no máximo 52 minutos no ano inteiro. Veja a tabela completa, o conceito de error budget e como medir uptime de forma honesta.
- A diferença real entre 99,9% e 99,99% de uptime em minutos de downtime por ano.
- Por que SLA contratual ≠ SLA percebido pelo cliente.
- O conceito de error budget aplicado a e-commerce.
- Como medir e comunicar uptime de forma honesta (e o que não contar como downtime).
"Nosso site tem 99,99% de uptime" — frase que aparece em qualquer landing page de hospedagem. Soa bonito, mas o que esse número significa de fato? E, mais importante: como você prova isso pro seu cliente B2B que está cobrando SLA no contrato? Este guia é a matemática prática dos noves, sem marketing.
A tabela dos noves
Cada "nove" adicional divide o downtime por 10. Não é incremento linear — é exponencial. Custa cada vez mais caro garantir cada nove extra.
| SLA | Downtime/dia | Downtime/mês | Downtime/ano |
|---|---|---|---|
| 99% | 14 min 24 s | 7 h 18 min | 3 d 15 h 36 min |
| 99,5% | 7 min 12 s | 3 h 39 min | 1 d 19 h 48 min |
| 99,9% | 1 min 26 s | 43 min 49 s | 8 h 45 min 57 s |
| 99,95% | 43 s | 21 min 54 s | 4 h 22 min 58 s |
| 99,99% | 8,6 s | 4 min 22 s | 52 min 35 s |
| 99,999% | 0,86 s | 26 s | 5 min 15 s |
Error budget: o orçamento de falha
O Google formalizou o conceito de error budget (orçamento de erro) em SRE: se você assume um SLA de 99,9%, você "gasta" 0,1% de tempo em queda — e isso é OK, é parte do orçamento.[1]
Quando o orçamento ainda está positivo, a equipe pode tomar riscos: lançar feature nova, migrar banco, atualizar versão. Quando o orçamento foi gasto, prioridade vira estabilidade — nada de lançamento até o budget se recuperar no próximo período.
Esse mecanismo destrava a tensão clássica entre dev (quer entregar) e ops (quer estabilidade). Vira política, não negociação.
Como medir uptime de forma honesta
O que conta como downtime
- HTTP 5xx ou conexão recusada para usuário final.
- Latência maior que limite (geralmente p99 > 10s na home). Latência catastrófica é downtime efetivo.
- Resposta válida mas conteúdo errado — página em branco com 200, erro JavaScript fatal. Por isso navegação real (Chromium) é mais confiável que ping.
O que não conta (e por quê)
- Falha do usuário — internet do cliente cai, problema de DNS local. Você não tem como controlar.
- Janela de manutenção pré-anunciada com aviso de pelo menos 7 dias. Tem que estar no contrato.
- Falha de provedor de terceiro não exclusivo — Cloudflare global, AWS region. Discutível: depende do contrato.
SLA na prática: medindo de onde?
Uptime medido de um único ponto mente para os dois lados:
- Mente para mais: se medir do mesmo data center, vai dar 99,99% mesmo se a borda de internet entre seu data center e o usuário cair.
- Mente para menos: se medir de uma região e a conexão entre essa região e sua loja oscila, vai contar como sua queda algo que é só rota.
A boa prática é medir de 3+ regiões geograficamente distintas, com regra de quórum: só conta como queda se 2 de 3 regiões falham simultaneamente. Isso elimina ruído de roteamento.
A página de status pública
Se você vende B2B ou tem clientes que dependem da sua loja para vender (marketplaces, plataformas), página de status pública é obrigatória. Ela:
- Tira do SAC dezenas de perguntas a cada incidente.
- Demonstra transparência — o que vale ouro em renegociação de contrato.
- Dá histórico que protege em disputa: "no dia X estávamos com 99,7%, dentro do SLA".
A Especialista Loja Virtual gera página de status pública automaticamente — veja como funciona.
Resumo prático
- Saiba o seu SLA real antes de prometer um número. Meça por 90 dias com retries e quórum.
- Negocie exceções específicas, não genéricas. "Falha de terceiros" vira "falha de [provedor X listado em anexo]".
- Use error budget como ferramenta de decisão, não punição.
- Comunique antes do cliente perguntar. Status page pública é mais barato que SAC.
Referências
- Beyer et al. Site Reliability Engineering — How Google Runs Production Systems. O'Reilly, 2016 — cap. 3 (Embracing Risk) e cap. 4 (Service Level Objectives). sre.google/books
- Atlassian. SLA, SLO and SLI — definitions and best practices. atlassian.com/incident-management
- AWS. Service Level Agreements — Amazon EC2, RDS, CloudFront. aws.amazon.com/legal/sla
- Cloudflare. Public Service Status & Incident History. cloudflarestatus.com
- Brasil. Resolução ANEEL 482/2012 e ANATEL — referência para SLA setorial.
Perguntas frequentes
- Qual SLA prometer pro meu cliente B2B?
- 99,9% é o ponto realista para a maioria das lojas que opera sem multi-region. Promete 8h45 de queda no ano — espaço suficiente para imprevisto. Acima disso (99,95% ou 99,99%) exige investimento em failover real, não dá para prometer só pela hospedagem.
- Janela de manutenção pode ficar fora do cálculo?
- Sim, desde que (1) seja pré-anunciada com pelo menos 7 dias e (2) esteja explicitamente listada no contrato. Sem isso, qualquer tempo offline conta como downtime.
- Se a AWS cair, vale como SLA do cliente?
- Discutível. Do ponto de vista do cliente final, você caiu — não importa de quem foi a culpa. Em contrato B2B, negocie exclusão específica ("falha de [provedor X]") em vez de "qualquer terceiro".
Continue lendo
Monitore tudo isso automaticamente
A Especialista Loja Virtual roda navegação real no seu site a cada poucos minutos, alerta no Discord, Slack ou e-mail e mostra screenshot do incidente. Comece grátis.