Como este tema funciona na sua empresa
Aceita SLA padrão do provedor (geralmente 99.9%). Confia em plataforma consolidada (AWS, Azure, Google Cloud). Não faz cálculo de impacto econômico de downtime. Abordagem prática: implementar backup próprio em segunda região como redundância — não confiar apenas em SLA do provedor.
Negocia SLA customizado para aplicações críticas (99.99%). Monitora cumprimento com ferramentas independentes (Pingdom, Uptime Robot). Contrato inclui créditos de downtime (10-20% da fatura mensal). Abordagem: definir SLA por tier de aplicação, validar independentemente, cobrar créditos sistematicamente.
SLA diferenciados por serviço (99.99% ou 99.999%). Multi-cloud com SLAs agregados. Monitoramento terceirizado (ThousandEyes, NETSCOUT). Contrato com compensação significativa. Auditoria regular de cumprimento. Abordagem: automação de monitoramento, escalation automática, cobrança de créditos integral.
SLA de cloud (Service Level Agreement) é o contrato entre empresa e provedor cloud que promete nível específico de disponibilidade (uptime percentual), performance, e compensação financeira se a promessa for violada. SLA é promessa de reembolso, não promessa de que falha não acontecerá.
O que é SLA e por que não é o mesmo que uptime garantido
Confusão comum: "Contratei 99.9% SLA, então minha aplicação não cai". Realidade: 99.9% permite 43 minutos de downtime por mês. Se aplicação cai por 1 hora, provedor viola SLA e oferece crédito (geralmente 10-30% da fatura). Crédito não compensa totalmente perda de negócio — é apenas reembolso parcial.
SLA é métrica de responsabilidade do provedor, não de risco de negócio. Para mitigar risco de negócio, empresa deve: implementar redundância própria (multi-cloud, backup), desenhar arquitetura resiliente, ter plano de disaster recovery.
Escalas comuns de SLA:
- 99% uptime = 7 horas de downtime permitido por mês
- 99.9% uptime = 43 minutos de downtime por mês (padrão AWS/Azure)
- 99.99% uptime = 4 minutos de downtime por mês (aplicações críticas)
- 99.999% uptime = 26 segundos de downtime por mês (ultra-críticas, raro)
Componentes de um SLA robusto: o que exigir do provedor
SLA mínimo deve conter:
- Uptime: percentual de tempo que serviço deve estar disponível. Exemplo: 99.99% para EC2 em AWS.
- Performance: latência máxima garantida (opcional mas importante). Exemplo: <20ms para dados em mesma região.
- Throughput: volume mínimo de requisições por segundo. Importante para APIs.
- Disaster Recovery (RTO/RPO): Tempo máximo para restaurar (RTO), tempo máximo de dados perdido (RPO). Exemplo: RTO <4 horas, RPO <1 hora.
- Créditos por violação: Quanto provedor reembolsa se violar. Exemplo: 10% do valor mensal para cada hora de violação, máximo 30% da fatura.
- Exclusões: O que não conta como violação (manutenção agendada, força maior, ações do cliente). Ler pequena letra é crítico.
- Claim process: Como reportar violação, prazo para reclamação, documentação necessária.
Como negociar SLA customizado com provider
Provedores cloud públicos publicam SLA padrão. Alguns termos podem ser negociáveis dependendo de volume/contrato:
Pontos para negociar:
- Aumento de SLA de 99.9% para 99.99% — pode ter custo, vale perguntar se há desconto por volume.
- Redução de exclusões — "manutenção agendada não conta como violação" afeta seu cálculo, tente restringir a X horas por trimestre agendadas.
- Aumento de créditos — de 10% para 20% ou 30%.
- Inclusão de performance SLA — latência máxima garantida.
- RTO/RPO explícito — sobretudo para backup e disaster recovery.
Leverage para negociação: Volume (quanto você vai gastar), multi-cloud (ameaça de sair), criticidade da aplicação (demonstrar impacto de violação).
Calculando o impacto econômico de downtime
Para entender se SLA vale a pena, calcular quanto custa 1 minuto de downtime:
Exemplo: E-commerce com 10 mil clientes simultâneos, conversão 5%, valor médio R$ 500 = R$ 25 milhões de receita/hora. Portanto, 1 minuto de downtime = R$ 417 mil de receita potencial perdida.
Com 99.9% SLA: máximo 43 minutos de downtime/mês = máximo R$ 18 milhões de perda potencial (sem crédito de SLA).
Com 99.99% SLA: máximo 4 minutos de downtime/mês = máximo R$ 1,6 milhão de perda potencial.
Diferença no custo de cloud para 99.99% (vs. 99.9%) pode ser 10-20% mais caro. Se custo adicional é menor que impacto de downtime, vale negociar.
Monitoramento independente de SLA
Não confiar apenas em métricas do provedor. Implementar monitoramento independente:
- Sonda sintética: Script que acessa sua aplicação a cada X minutos de múltiplas locações, registra downtime e latência. Ferramentas: Pingdom, UptimeRobot, Catchpoint.
- Real user monitoring: JavaScript embutido que coleta performance de usuários reais. Melhor do que sintético porque reflete experiência real.
- Log de eventos: Guardar timestamps de erros, timeouts, indisponibilidade em seus logs. Correlacionar com timeline de violação reportada.
Quando SLA é violado, provedor pode questionar — ter evidência independente é ouro para cobrança de créditos.
Diferença entre SLA, SLO e SLI
Termos frequentemente confundidos:
SLA (Service Level Agreement): Contrato entre empresa e provedor cloud. Promessa do provedor com compensação se violado.
SLO (Service Level Objective): Objetivo interno da empresa para seu serviço. Exemplo: "meu serviço deve ter 99.95% uptime" (mais rigoroso que SLA do provedor). SLO não tem compensação, é meta interna.
SLI (Service Level Indicator): Métrica técnica que mede SLA/SLO. Exemplo: "% de requisições que retornam em <100ms", "% de requisições sem erro". SLI é o número que você coleta.
Relação: SLI (métrica) ? SLO (objetivo interno) ? SLA (contrato externo).
Sinais de que sua empresa precisa renegociar SLA de cloud
Se você se reconhece em três ou mais cenários abaixo, é hora de revisar contrato.
- Aplicação crítica está em SLA padrão (99.9%) quando impacto de downtime é alto
- Provedor viola SLA regularmente, mas você não cobra créditos
- Não consegue calcular impacto econômico de downtime na sua aplicação
- Não tem monitoramento independente para validar cumprimento de SLA
- Contrato não especifica performance SLA (latência, throughput), só uptime
- Exclusões de SLA são amplas — manutenção agendada, DDoS isentam provedor
- RTO/RPO para disaster recovery não estão no contrato
Caminhos para estruturar SLA de cloud robusto
Definir SLA pode ser feito internamente ou com apoio.
Viável quando empresa tem expertise em negociação e entende seu SLA.
- Perfil necessário: Gerente de Infraestrutura ou Arquiteto Cloud com experiência em contratos.
- Tempo estimado: 1 a 2 meses para revisar contrato atual, definir SLA por tier, implementar monitoramento independente.
- Faz sentido quando: Empresa já opera em cloud e conhece suas necessidades.
- Risco principal: Negociar mal, aceitar exclusões amplas ou créditos baixos.
Recomendado para negociação de contrato enterprise ou quando empresa não tem experiência.
- Tipo de fornecedor: Consultoria de Cloud ou Consultoria Jurídica especializada em contratos de tecnologia.
- Vantagem: Expertise em negociação, conhecimento de práticas de mercado, redução de riscos legais.
- Faz sentido quando: Valor em jogo é grande ou aplicação é crítica para negócio.
- Resultado típico: Em 1 a 3 meses, contrato renegociado com termos mais favoráveis.
Precisa de apoio para estruturar SLA de cloud?
Se definir SLA apropriado e negociar com providers é prioridade, o oHub conecta você gratuitamente a consultores especializados em contratos cloud. Em menos de 3 minutos, descreva sua necessidade, receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que é SLA em cloud computing?
SLA (Service Level Agreement) é contrato entre empresa e provedor cloud que promete nível específico de disponibilidade (uptime percentual) e compensação se não for cumprido. Exemplo: "AWS garante 99.99% uptime para EC2; se violar, fornece crédito de 10% da fatura mensal".
Qual é o SLA padrão dos provedores cloud?
Maioria dos provedores (AWS, Azure, Google Cloud) oferece 99.9% SLA por padrão para compute (servidores virtuais). Alguns serviços gerenciados (banco de dados, storage) têm SLA mais alto (99.99%). SLAs específicos variam por serviço e região.
Como monitorar cumprimento de SLA?
Implementar sonda sintética (Pingdom, UptimeRobot) que testa sua aplicação periodicamente e registra downtime. Correlacionar com logs internos. Não confiar apenas em métricas do provedor — ter evidência independente.
Posso negociar SLA customizado com provider cloud?
Sim, em certos casos. SLA padrão é publicado, mas alguns termos podem ser negociáveis conforme volume de contrato. Pontos: aumento de SLA (99.9% para 99.99%), redução de exclusões, aumento de créditos, inclusão de performance SLA.
Como calcular impacto de violação de SLA?
Multiplicar receita por minuto (receita anual / 365 / 24 / 60) pela duração do downtime. Exemplo: empresa de R$ 100 milhões/ano perde R$ 190 mil por minuto de downtime. Crédito de 10% de fatura não compensa esse impacto — precisa de redundância própria.
Qual é a diferença entre uptime e performance SLA?
Uptime SLA: % de tempo que serviço está online. Performance SLA: latência máxima garantida (ex: <20ms). Aplicação pode estar online (uptime OK) mas lenta (performance SLA violado). Exigir ambos.