SLA na prática: como calcular uptime real e definir penalidades que funcionam

Janeiro deste ano. Reunião de crise num cliente do setor de saúde. O sistema de prontuário eletrônico ficou fora do ar por 6 horas na sexta-feira. Sábado de manhã, atendimento ambulatorial inteiro funcionando em papel.

O CIO mostrou o contrato. SLA de 99,5%.

Fizemos a conta. 99,5% em 30 dias = 3,6 horas de downtime permitido. Eles ficaram fora 6 horas. SLA violado.

Penalidade: crédito de 5% da mensalidade. Mensalidade de R$ 24 mil. Crédito: R$ 1.200.

Custo real do incidente para o hospital: R$ 180 mil em produtividade perdida, R$ 40 mil em pacientes redirecionados a outras unidades, custo reputacional impossível de quantificar mas claramente alto.

R$ 1.200 de crédito para R$ 220 mil de prejuízo.

Esse é o problema com SLA mal estruturado. Não protege ninguém quando o problema acontece.

A matemática do uptime que ninguém faz antes de assinar

Vamos ao básico que poucos calculam.

99% de uptime mensal = 7,2 horas de downtime permitido/mês.

99,5% = 3,6 horas/mês.

99,9% = 43 minutos/mês.

99,95% = 21 minutos/mês.

99,99% = 4,3 minutos/mês ("4 noves").

99,999% = 26 segundos/mês ("5 noves").

A diferença entre 99,9% e 99,99% parece pequena (0,09%). Operacionalmente, é a diferença entre 43 minutos de tolerância e 4,3 minutos. Dez vezes menos margem.

O custo de implementação muda dramaticamente entre cada nível. Operar com 99,9% é razoavelmente acessível com arquitetura cloud razoável. 99,99% exige redundância geográfica, automação avançada, equipe 24/7 dedicada. 99,999% exige praticamente uma operação militar.

A pergunta certa não é "qual o SLA do fornecedor?". É "qual o SLA que meu negócio precisa?".

Downtime planejado vs não-planejado: a distinção que muda tudo

SLA padrão exclui downtime planejado. "Janela de manutenção".

Isso é o que diferencia o SLA contratual do SLA real.

SLA contratual: 99,9% (excluindo manutenção).

SLA real: depende do tamanho da janela de manutenção.

Exemplo:

Janela de manutenção contratada: "até 8 horas mensais, em horário a definir pelo fornecedor com aviso prévio".

SLA real máximo (se o fornecedor usar toda a janela): 30 dias x 24h = 720h. Menos 8h de manutenção = 712h de operação contratada. 99,9% disso = 711,3h, ou seja, 0,7h de downtime adicional permitido.

Total possível de indisponibilidade: 8,7h por mês.

Se essas 8h de manutenção batem no seu horário crítico (sábado de manhã para hospital, fim de mês para ERP, segunda-feira para varejo), o SLA contratual é fantasia. O SLA real é muito pior.

Negocie sempre a janela de manutenção como variável crítica do SLA, não como detalhe secundário.

Como calcular o custo real de uma hora de indisponibilidade

Pergunta direta: quanto uma hora de indisponibilidade custa para seu negócio?

Se você não sabe responder com número específico, não pode negociar SLA decentemente.

Componentes do custo:

1. Receita perdida

Receita média horária do sistema durante o horário do incidente. Não é (receita anual / 8760 horas). É a receita real daquela faixa horária.

E-commerce em horário de pico (sexta à noite) pode ter receita 5-8x a média. Hospital em horário ambulatorial (segunda a sexta, 8h-18h) tem receita concentrada.

2. Produtividade perdida

Número de funcionários que dependem do sistema x custo médio carregado por hora x duração do incidente x fator de produtividade perdida (geralmente 40-80%, raramente 100%).

Para 200 funcionários a R$ 80/h com 60% de produtividade perdida em 1h: 200 x 80 x 0,6 = R$ 9.600.

3. Custo de recuperação

Equipe técnica em modo crise, eventualmente fornecedores externos chamados em regime de urgência, infraestrutura adicional alocada temporariamente.

4. Custo de oportunidade

Atividades planejadas pausadas para tratar a crise. Reuniões canceladas. Projetos atrasados.

5. Custo reputacional

Mais difícil de quantificar mas real. Clientes que ficaram sem atendimento, parceiros que percebem fragilidade, eventuais menções negativas em mídia social.

Some os 5 componentes. Esse é o custo da hora de indisponibilidade no seu negócio.

Para empresas de porte médio em setor regulado, varia tipicamente entre R$ 30 mil e R$ 250 mil por hora.

Penalidades que funcionam vs penalidades decorativas

Já vi muitos tipos de penalidade em contrato. A maioria é decorativa.

Penalidades decorativas

• Crédito de 1-5% da mensalidade por violação (irrelevante)
• Crédito que vence em 90 dias se não utilizado
• Crédito que só pode ser usado em compras adicionais (você compra mais para usar o crédito do problema deles)
• Penalidade com teto máximo mensal cobrindo só uma fração do impacto possível

Penalidade decorativa não muda o comportamento do fornecedor. Ele paga e segue a vida. O incentivo para investir em prevenção é fraco.

Penalidades que funcionam

• Crédito escalonado: 15% primeira violação trimestral, 30% segunda, 50% terceira
• Devolução em dinheiro, não em crédito
• Indenização sobre prejuízo comprovado (até teto significativo, por exemplo 3 vezes a anuidade)
• Direito de rescisão sem ônus após 3 violações consecutivas
• Direito de auditar logs do fornecedor para validar cálculo do SLA

Penalidade que funciona muda comportamento. O fornecedor investe em redundância, em melhoria de processo, em redundância porque o custo de não fazer é alto demais.

O SLA que eu negocio para sistemas críticos

Para sistemas críticos de cliente em setor regulado, o SLA tem 6-8 métricas e penalidades estruturadas. Te dou a estrutura padrão:

1. Uptime

99,9% para sistemas críticos. 99,99% para core bancário ou similar. Janela de manutenção limitada a 4h/mês, em horário não-crítico definido pelo cliente, com aviso de 7 dias.

2. Performance

Tempo de resposta para transações críticas. Para web típica, p95 < 2 segundos. Para core de aplicação, p99 < 500 ms.

3. Tempo de resposta a incidente

P1: reconhecimento em 15 min, primeira ação em 30 min, comunicação ao cliente em 30 min.

P2: reconhecimento em 1h, primeira ação em 2h, comunicação em 1h.

4. Tempo de resolução

P1: 4 horas máximo. P2: 8 horas. P3: 24 horas. P4: 5 dias úteis.

5. Limite de incidentes

Máximo de 1 incidente P1 por trimestre. Mais que isso gera direito de rescisão.

6. RPO/RTO

RPO (Recovery Point Objective — perda máxima de dados): geralmente 5-15 minutos para sistemas críticos.

RTO (Recovery Time Objective — tempo máximo de recuperação após desastre): 2-4 horas para sistemas críticos.

7. Comunicação

Frequência de updates durante incidente P1 (a cada 30 min). Relatório pós-incidente em 5 dias úteis com causa raiz e plano de prevenção.

8. Penalidades

Crédito escalonado em dinheiro + direito de rescisão após X violações + cláusula de indenização para prejuízos comprovados.

SLA bem estruturado é defesa do negócio. SLA com uma linha de uptime é só formalidade jurídica que não te protege quando precisa.

RTO e RPO: as métricas de continuidade que SLA esquece

SLA típico fala de uptime. Não fala de recuperação após desastre.

RPO (Recovery Point Objective): quanto de dado pode ser perdido em incidente. Se RPO é 1 hora, no pior cenário você perde até 1 hora de transações.

RTO (Recovery Time Objective): em quanto tempo o sistema volta após desastre.

Para sistemas críticos:

• RPO < 15 min (replicação síncrona ou quase)
• RTO < 4h (failover automático ou semi-automático)

Esses números precisam estar no SLA. Sem eles, em cenário de desastre, fornecedor pode demorar 48-72h para recuperar — e estar tecnicamente dentro do contrato.

Auditoria independente do SLA reportado

SLA reportado pelo fornecedor é parte interessada. Validar com terceiro:

• Ferramenta externa de monitoramento (Pingdom, UptimeRobot, custom)
• Comparação mensal entre reportado e medido independente
• Direito contratual de auditar logs em caso de divergência

Em 12 dos 15 contratos que auditei nos últimos 2 anos, havia divergência entre o SLA reportado e o medido independentemente. Em 4 casos, a divergência era material (acima de 0,5%).

SLA em contrato de software customizado: ajuste necessário

SLA padrão funciona para SaaS pronto. Para software customizado, precisa ajuste.

Em desenvolvimento customizado, a disponibilidade depende de:

• Infraestrutura (que pode ser do cliente ou do fornecedor)
• Aplicação customizada (de responsabilidade do fornecedor que desenvolve)
• Integrações com terceiros (responsabilidade compartilhada)

O SLA precisa diferenciar essas camadas. Aplicação caiu por bug do código que o fornecedor entregou — fornecedor responde. Aplicação caiu por infraestrutura — depende de quem hospeda. Aplicação caiu por integração com terceiro — análise caso a caso.

SLA de software customizado mal estruturado vira fonte de litígio infinito. SLA bem estruturado define escopo de responsabilidade com clareza.

Em resumo: SLA bem estruturado em 8 pontos

1. Uptime mensal específico para criticidade do sistema (99,9% / 99,99% / 99,999%)
2. Janela de manutenção limitada e em horário definido pelo cliente
3. SLA de performance (não só disponibilidade)
4. Tempo de resposta a incidente por severidade
5. Tempo de resolução por severidade
6. RPO e RTO definidos
7. Penalidade em dinheiro escalonada + direito de rescisão
8. Auditoria independente com direito de validar logs

SLA com esses 8 pontos é proteção contratual real. Sem eles, você tem documento bonito que não te ajuda quando o problema acontece.

Quando renegociar SLA existente

Não é só na assinatura que se negocia SLA. Renegociação durante a vida do contrato é legítima quando há mudança material no contexto.

Gatilhos que justificam renegociação:

• Volume de uso aumentou significativamente (você se tornou cliente maior, ganha alavancagem)
• Sistema passou a ser mais crítico para o negócio (justifica SLA mais apertado)
• Concorrência do fornecedor melhorou (você tem opção real de troca)
• Histórico recente mostra problemas que o SLA atual não cobre adequadamente

Fornecedor maduro topa renegociar quando o cliente apresenta argumento defensável. Fornecedor que se recusa categoricamente está te sinalizando algo — geralmente que não valoriza a relação no longo prazo.

Faça renegociações periódicas (a cada 12-18 meses) parte do ciclo natural da relação, não evento excepcional.

Se você está negociando ou revisando contrato com SLA, vale a pena passar pela calculadora antes. Te dá o número de custo de downtime do seu negócio, que é o argumento que sustenta toda a negociação.

Os modelos de cálculo: por mês, trimestre ou rolling window

Pequena variação que faz grande diferença no SLA real: como o uptime é medido. Três modelos coexistem no mercado, e a escolha define o que o cliente realmente recebe.

Mensal. O modelo mais comum em cloud pública (AWS, Azure, Google). Uptime é medido em cada mês calendário, multa é calculada sobre o mês. Vantagem: simplicidade. Desvantagem: incidente material no final do mês pode estourar SLA sem que o cliente tenha tempo de reação ou negociação.

Trimestral. Modelo intermediário. Uptime medido em janela de 90 dias. Vantagem: maior estabilidade na medida. Desvantagem: cliente fica exposto a período maior antes que ações corretivas sejam disparadas.

Rolling window de 30 dias. Modelo mais protetor. A janela de medida desliza diariamente. Vantagem: detecção contínua de degradação. Desvantagem: complexidade no acompanhamento e na geração de relatório.

Para sistemas críticos, recomendo rolling window. Para sistemas menos críticos, mensal funciona. Trimestral é raramente a melhor escolha — fica longa demais para SLA reativo e curta demais para análise estratégica.

Tempo de indisponibilidade: o que conta e o que não conta

Definição crucial e frequentemente ambígua: o que conta como "indisponibilidade" no cálculo do SLA? Cada provedor define diferente, e a diferença é significativa.

Pontos típicos de divergência: janela de manutenção planejada (geralmente não conta — mas qual é a janela?); incidentes que afetam apenas parte da capacidade (50% dos servidores fora, considera 100% ou 50% de indisponibilidade?); incidentes que duram menos que o threshold mínimo (5 minutos? 10 minutos?); degradação de performance sem indisponibilidade completa (latência alta conta?); incidentes de causa externa (BGP, DNS upstream, ataque DDoS contra terceiros).

Contrato bom define cada um desses pontos explicitamente. Contrato vago vira disputa interminável no primeiro incidente material.

Recomendação prática: insistir em definição clara, com exemplos concretos no anexo do contrato. "Indisponibilidade total" deve incluir indisponibilidade parcial proporcionalmente, degradação grave de performance acima de threshold definido (ex.: latência 5x acima do baseline), e janelas de manutenção não comunicadas com antecedência mínima.

Multa por descumprimento: o que torna efetiva

Sem multa real, SLA é declaração de intenção. Mas multa simbólica também não funciona — fornecedor absorve como custo operacional e ignora o impacto. Multa efetiva tem três características.

Proporcional ao impacto: não é 1% do contrato fixo — é escala crescente. Por exemplo: descumprimento de 0,1-0,5% de uptime = 5% do valor mensal; 0,5-1% = 15%; acima de 1% = 30%; descumprimento sucessivo em 3+ meses = 50% + direito de rescisão.

Auto-executável: a multa é aplicada automaticamente no faturamento seguinte, sem que o cliente precise formalizar pedido. Cláusula contratual ativa.

Cumulativa por categoria de SLA: uptime, tempo de resposta, tempo de resolução, qualidade de atendimento. Cada categoria gera multa independente, somáveis no mesmo período.

Em muitos contratos, a multa fica em 5-10% do valor mensal — irrelevante para o fornecedor e para o cliente. Em contratos sérios, chega a 30-50% em casos graves. Faz diferença real.