Uptime e SLA de 99,9%: o que significam na prática

"99,9% de uptime" aparece em quase toda página de hospedagem. O número soa como garantia de que o serviço quase nunca cai, mas diz pouco sem duas informações: o período em que ele é medido e o que acontece quando não é cumprido.

Antes de depender dele, vale saber fazer a conta e distinguir uma meta interna de um contrato com compensação.

O que é uptime?#

Uptime é o percentual do tempo em que um serviço esteve disponível dentro de um período. A fórmula é simples:

uptime = (tempo total - tempo fora do ar) / tempo total x 100

Se um app ficou 20 minutos fora do ar em um mês de 30 dias (43.200 minutos), o uptime foi de 99,954%. A medida só faz sentido com uma definição clara de "disponível". Pode ser responder HTTP 200 em até 5 segundos, aceitar uma conexão TCP ou, no caso de um bot, estar conectado ao Gateway. Cada definição dá um número diferente para o mesmo incidente.

Quanto downtime cada percentual permite?#

Para achar o downtime permitido, multiplique o período pela fração de indisponibilidade (100% menos o uptime):

Você pode refazer a conta para qualquer valor em Node.js:

const minutosNoMes = 30 * 24 * 60; // 43200

for (const uptime of [99, 99.9, 99.99, 99.999]) {
  const downtime = minutosNoMes * (1 - uptime / 100);
  console.log(`${uptime}% -> ${downtime.toFixed(2)} min/mês`);
}

Cada "nove" a mais divide o downtime permitido por dez. O livro de SRE do Google descreve cada nove adicional como uma melhoria de uma ordem de grandeza rumo aos 100%, e afirma que 100% provavelmente nunca é a meta certa de confiabilidade.

Qual a diferença entre SLI, SLO e SLA?#

Os três termos se confundem, mas descrevem camadas diferentes:

• SLI (indicador de nível de serviço): o que você mede. Exemplo: a fração de requisições respondidas com sucesso.
• SLO (objetivo de nível de serviço): a meta interna para o SLI. Exemplo: 99,9% das requisições com sucesso em 30 dias. Quem define é a equipe que opera o serviço.
• SLA (acordo de nível de serviço): o contrato com o cliente. Inclui um SLO e as consequências de descumpri-lo.

Na prática, um SLO é uma meta, e um SLA é uma meta com compensação financeira. Nenhum dos dois impede a queda. O livro de SRE também apresenta o orçamento de erro: o downtime que o SLO tolera. Com um SLO de 99,9% medido em 30 dias, o orçamento é de 43,2 minutos, e a equipe pode "gastá-lo" em deploys e manutenção em vez de perseguir o zero.

O que um SLA realmente garante?#

Quase sempre, um SLA garante uma compensação, não a disponibilidade. Tome como exemplo o formato do SLA regional do Amazon EC2: um compromisso de disponibilidade por ciclo mensal de cobrança, com compensação em créditos que crescem conforme o uptime cai. A tabela abaixo mostra um SLA hipotético nesse formato, com percentuais redondos escolhidos para facilitar a leitura. Não são os de nenhum fornecedor; os valores reais estão na página oficial do SLA.

Repare em quatro detalhes que se repetem em quase todos os SLAs:

1. O crédito é sobre a fatura do serviço afetado (na AWS, a fatura do mês do EC2 na região afetada), não sobre o prejuízo que você teve com a queda.
2. Você precisa pedir. No caso da AWS, abrindo um chamado com datas, recursos afetados e logs, até o fim do segundo ciclo de cobrança depois do incidente.
3. Crédito não é reembolso. Ele abate cobranças futuras.
4. Há condições de arquitetura. O SLA regional do EC2 só vale para instâncias distribuídas em duas ou mais zonas de disponibilidade.

Fora isso, SLAs costumam excluir manutenção programada, falhas causadas pelo cliente e eventos de força maior. Leia sempre a seção de exclusões antes de comparar dois fornecedores.

Por que o uptime do seu app pode ser menor que o da hospedagem?#

O percentual do fornecedor mede a infraestrutura dele. O seu app depende de mais coisas em série, e a disponibilidade total é o produto das partes. Hospedagem a 99,9%, banco a 99,9% e uma API externa a 99,9% dão 0,999 x 0,999 x 0,999, ou cerca de 99,7%: perto de 2,2 horas por mês.

E várias causas comuns de queda ficam fora de qualquer SLA de infraestrutura:

• exceções não tratadas que encerram o processo;
• falta de memória (o processo é morto por estourar a RAM);
• deploys com reinício, que derrubam o app por alguns segundos;
• tokens revogados, certificados vencidos e domínios expirados.

Por isso, vale medir por conta própria. Um monitor externo que testa o app a cada minuto dá o número que importa: o que o seu usuário viu. Para bots sem porta HTTP, veja como monitorar o uptime de um bot.

Quanto uptime você realmente precisa?#

Depende do custo de ficar fora do ar, não do número mais alto possível:

• 99% (cerca de 7 h por mês): serve para projeto pessoal, ferramenta interna ou bot de comunidade pequena.
• 99,9% (cerca de 43 min por mês): padrão razoável para sites e APIs comerciais de pequeno e médio porte.
• 99,99% ou mais: exige redundância real, com várias instâncias, failover automático e, em geral, mais de uma região. O custo e a complexidade sobem muito. Veja o que é um load balancer para a base dessa arquitetura.

Vale a ressalva do livro de SRE: o usuário comum não distingue 99,99% de 99,999% quando o próprio celular e a rede dele são menos confiáveis que isso. Quase todo projeto começa bem servido com 99,9%.

Se você ainda está escolhendo onde hospedar, compare também o modelo de operação em VPS ou plataforma de nuvem: em um VPS, patch, reinício e monitoramento são tarefa sua.

Como fazer isso na Square Cloud#

A mesma leitura vale na Square Cloud: disponibilidade é uma meta, não uma garantia. As aplicações rodam em containers isolados sempre ligados, sem cold start nem modo de suspensão, e o reinício automático (ligado por padrão no deploy pelo painel) religa a aplicação quando o processo encerra com erro. O uptime médio observado é de 99,99%, um dado histórico, não a promessa de que o serviço nunca vai parar.

Boa parte do uptime continua do seu lado: tratar exceções, dimensionar a RAM de cada aplicação e acompanhar logs e métricas em tempo real no painel. Para alta disponibilidade de um site ou API, o load balancing, a partir do plano Standard, distribui um domínio personalizado entre várias aplicações, em round-robin com failover passivo. Não há autoscaling: você escolhe quantas aplicações e quanta RAM usar.

No plano Enterprise, um SLA pode ser discutido com a equipe. Os recursos de disponibilidade e monitoramento estão na página de recursos.