Provedor que está começando a vender cloud costuma tratar o SLA como material de marketing: escolhe um número bonito, coloca no site e segue em frente. O problema é que SLA não é marketing — é cláusula contratual com consequência financeira. E o número escolhido sem conta não é apenas otimista: ele cria uma obrigação que a sua infraestrutura não consegue cumprir, e a fatura chega em forma de crédito, renegociação e cliente perdido.
Um número sozinho não significa nada
"Disponibilidade de 99,9%" é uma frase incompleta. Para virar compromisso operável, ela precisa responder quatro perguntas:
- Disponibilidade de quê? Da VM ligada? Da rede alcançável? Do serviço do cliente respondendo? São coisas diferentes, com dificuldades muito diferentes. O usual e defensável é comprometer-se com a infraestrutura: a VM ligada e alcançável pela rede. O que roda dentro dela é responsabilidade de quem a administra.
- Medido onde? Verificação a partir de dentro da sua rede mostra números melhores e menos verdadeiros. Medição externa é mais honesta e mais defensável em disputa.
- Em qual janela? Mensal é o padrão de mercado e é mais favorável ao cliente que anual — no anual, uma queda longa se dilui.
- Excluindo o quê? Esta é a mais importante, e a próxima seção trata dela.
O que não conta como indisponibilidade
Sem exclusões explícitas, você assumiu responsabilidade por coisas que não controla. O que precisa estar escrito:
- Janela de manutenção programada, anunciada com antecedência definida. Sem essa cláusula, toda atualização de segurança é tecnicamente uma violação do contrato.
- Ação ou configuração do cliente. Cliente que derruba a própria aplicação, esgota o disco ou bloqueia o próprio acesso com regra de firewall não gerou indisponibilidade sua.
- Suspensão por inadimplência ou por violação de política de uso.
- Falha em serviço de terceiro fora do seu perímetro, incluindo o provedor de conectividade do próprio cliente.
- Ataque volumétrico além da capacidade contratada de mitigação — com cuidado, porque exclusão ampla demais esvazia a promessa.
- Caso de força maior, com definição objetiva.
Um cuidado de redação: exclusões precisam ser específicas. Cláusula vaga que exclui "qualquer causa fora do controle do provedor" pode ser lida como abusiva e, pior, destrói a credibilidade comercial do compromisso.
A conta que impede prometer o impossível
Aqui está a parte técnica que decide o número, e ela é implacável: o seu SLA não pode ser melhor que o da sua dependência mais fraca.
Se você opera em datacenter com compromisso de 99,9%, prometer 99,99% ao cliente é assumir a diferença com o próprio bolso. E dependências em série se multiplicam: energia, conectividade, hardware e plataforma, cada um com a própria disponibilidade, resultam num número inferior ao menor deles.
| Meta | Indisponibilidade/mês | O que ela exige de verdade |
|---|---|---|
| 99,5% | ~3h40 | Monitoramento com alerta e plantão organizado |
| 99,9% | ~43min | Cluster com HA, storage redundante, link redundante |
| 99,95% | ~22min | Energia e refrigeração redundantes, failover ensaiado |
| 99,99% | ~4min | Redundância ponta a ponta, sem manutenção com parada |
Duas leituras práticas. 99,9% já exige cluster de verdade — três nós, storage redundante, quórum correto. Um nó único não sustenta esse número, e prometê-lo é uma dívida assumida antecipadamente. E 99,99% raramente é sustentável para provedor regional, porque exige eliminar toda parada planejada e ter redundância em cada camada, inclusive no datacenter.
A orientação comercial que funciona: prometa o que você sustenta com folga e entregue acima. Cliente que recebe 99,97% com promessa de 99,5% fica satisfeito. O inverso gera crédito e desconfiança.
O crédito, estruturado com cuidado
O crédito é a consequência do descumprimento, e a estrutura importa mais que o percentual:
- Escalonado por faixa de indisponibilidade, não valor único.
- Percentual da mensalidade daquele serviço, nunca do contrato inteiro nem de valor absoluto.
- Com teto, tipicamente a mensalidade do mês. Sem teto, uma falha longa pode gerar obrigação maior que toda a receita do cliente.
- Mediante solicitação, com prazo definido para o cliente pedir e obrigação de apresentar evidência.
- Como crédito em fatura futura, não devolução em dinheiro.
E o ponto que preserva a operação: o crédito é o limite da responsabilidade por indisponibilidade. Sem essa cláusula, você fica exposto a pedido de indenização por lucro cessante do cliente, que é um risco de outra ordem de magnitude.
A assimetria que ninguém calcula
Este é o risco mais específico da revenda, e o menos compreendido.
Suponha que você paga determinado valor pela infraestrutura e revende com margem. Quando o seu fornecedor falha, o crédito que você recebe é proporcional ao que você paga a ele. O crédito que você deve aos seus clientes é proporcional ao que eles pagam a você — um valor bem maior, multiplicado por todos os clientes afetados.
Uma falha única do fornecedor pode gerar obrigação de crédito para dezenas de clientes, com compensação recebida de apenas um contrato. A diferença sai da sua margem.
Três defesas: não prometa mais do que o seu fornecedor promete; mantenha teto de crédito por cliente e por mês; e considere o custo esperado de crédito na sua precificação, como qualquer outro custo previsível. Provedor que ignora isso descobre a conta no primeiro incidente grande.
Janela de manutenção é um ativo
Provedor que não define janela de manutenção acaba em uma de duas situações ruins: adia atualização de segurança para não violar o SLA, ou atualiza e viola.
Defina explicitamente no contrato: período recorrente — uma faixa de horário em dias de menor uso —, aviso prévio com prazo definido, limite de duração por janela e por mês, e um procedimento distinto para manutenção emergencial de segurança, com aviso menor e justificativa.
Clientes aceitam janela de manutenção com naturalidade quando ela é previsível e comunicada. O que gera atrito é a parada não anunciada.
Disponibilidade e suporte são compromissos separados
Confundir os dois gera expectativa mal calibrada. São dois compromissos distintos, e o segundo é frequentemente o que o cliente mais sente:
- Disponibilidade é sobre a infraestrutura estar de pé.
- Suporte é sobre tempo de primeira resposta por severidade, canal de atendimento, horário de cobertura e caminho de escalonamento.
Prometa tempo de primeira resposta, não tempo de solução. Solução depende da natureza do problema, e comprometer-se com prazo de resolução para algo desconhecido é assumir risco sem controle.
Você precisa poder provar
SLA sem medição é promessa sem verificação, e em disputa a falta de dado joga contra quem prometeu. O mínimo:
- Monitoramento externo com histórico retido por período maior que a janela de contestação.
- Página de status hospedada fora da sua infraestrutura — dentro dela, fica indisponível exatamente quando é necessária.
- Registro de incidentes com início, fim, causa e serviços afetados.
- Relatório mensal de disponibilidade, pelo menos para os contratos maiores. Transparência proativa reduz contestação, porque o cliente não precisa acreditar: ele vê.
Erros comuns
- Escolher o número por marketing, sem verificar as dependências.
- Prometer mais do que o fornecedor de infraestrutura promete.
- SLA sem definição do que conta como indisponibilidade.
- Nenhuma janela de manutenção prevista.
- Crédito sem teto, expondo mais que a receita do cliente.
- Não limitar a responsabilidade ao crédito.
- Ignorar a assimetria entre crédito recebido e crédito devido.
- Medir disponibilidade de dentro da própria rede.
- Página de status na infraestrutura que cai.
- Prometer prazo de solução em vez de prazo de primeira resposta.
- Prometer 99,9% com nó único.
Onde a Solvefy/Cloud entra
Ajudamos provedores a montar esse compromisso de forma sustentável: calculamos o número que a sua infraestrutura sustenta de fato, escrevemos as definições e exclusões que protegem a operação sem esvaziar a promessa, estruturamos crédito com teto e dimensionamos a assimetria de revenda na precificação. E, no lado técnico, projetamos o cluster que suporta o número prometido — porque SLA se sustenta em quórum correto, storage redundante e backup testado, não em texto de contrato. É parte do onboarding da plataforma E-CLOUD.
Quer saber qual SLA a sua infraestrutura sustenta hoje? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.