SLA de verdade para revenda de cloud: o que prometer e como sustentar

SLA é promessa com consequência financeira. Como definir o que conta como indisponibilidade, por que seu SLA não pode superar suas dependências e o risco da assimetria.

Equipe Solvefy 7 min de leitura

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:

  1. 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.
  2. 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.
  3. Suspensão por inadimplência ou por violação de política de uso.
  4. Falha em serviço de terceiro fora do seu perímetro, incluindo o provedor de conectividade do próprio cliente.
  5. Ataque volumétrico além da capacidade contratada de mitigação — com cuidado, porque exclusão ampla demais esvazia a promessa.
  6. 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.

MetaIndisponibilidade/mêsO que ela exige de verdade
99,5%~3h40Monitoramento com alerta e plantão organizado
99,9%~43minCluster com HA, storage redundante, link redundante
99,95%~22minEnergia e refrigeração redundantes, failover ensaiado
99,99%~4minRedundâ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ê.

Faça agora o seu diagnóstico e orçamento

Inicie com um diagnóstico gratuito da sua infraestrutura e receba uma proposta personalizada — com escopo, cronograma e valores.