SLA de Tecnologia

Quando uma empresa contrata um serviço de tecnologia — hospedagem, ERP em nuvem, plataforma de pagamentos, suporte de TI — há um conjunto de expectativas sobre como o serviço deve funcionar: disponibilidade, tempo de resposta a incidentes, performance mínima. O SLA é o documento que transforma essas expectativas em compromissos contratuais mensuráveis.

SLA — Service Level Agreement, Acordo de Nível de Serviço — é o contrato que define o nível mínimo de qualidade que um fornecedor de serviço se compromete a entregar, as métricas pelas quais esse compromisso é medido, e as consequências quando não é cumprido. Não é apenas proteção legal — é o instrumento que alinha expectativas entre quem contrata e quem entrega, tornando a gestão do serviço objetiva em vez de baseada em percepção subjetiva.

Disponibilidade: o compromisso mais comum em serviços de tecnologia. Expresso como percentual de tempo em que o serviço estará operacional num período (geralmente mensal ou anual). Os "noves" de disponibilidade são a forma padrão de comunicar esse compromisso:

Disponibilidade	Downtime mensal	Downtime anual
99% (dois noves)	~7,3 horas	~3,65 dias
99,9% (três noves)	~43,8 minutos	~8,76 horas
99,95%	~21,9 minutos	~4,38 horas
99,99% (quatro noves)	~4,4 minutos	~52,6 minutos
99,999% (cinco noves)	~26,3 segundos	~5,26 minutos

A diferença entre 99,9% e 99,99% parece pequena em percentual mas é enorme em impacto: de 43 minutos para 4 minutos de downtime mensal permitido.

Tempo de resposta e resolução de incidentes: quanto tempo o fornecedor tem para reconhecer (resposta) e resolver (resolução) incidentes, por severidade. Severidade 1 (sistema completamente indisponível): resposta em 15 minutos, resolução em 4 horas. Severidade 2 (funcionalidade crítica degradada): resposta em 1 hora, resolução em 8 horas. Os números variam enormemente entre fornecedores e tipos de serviço.

Performance: métricas de tempo de resposta máximo, throughput mínimo, latência. Mais comum em serviços de infraestrutura e APIs.

Suporte: canais disponíveis (e-mail, telefone, chat), horário de atendimento (horário comercial vs. 24/7), tempo de primeira resposta.

Janelas de manutenção: períodos planejados de indisponibilidade que geralmente não contam para o cálculo de disponibilidade.

No contexto interno de operações de tecnologia — e formalmente no modelo SRE (Site Reliability Engineering) do Google — existem três conceitos relacionados que merecem distinção.

SLI (Service Level Indicator): a métrica real que está sendo medida. Taxa de sucesso de requisições (%) é um SLI. Latência p99 (ms) é um SLI. Disponibilidade (%) é um SLI. São as medições brutas.

SLO (Service Level Objective): o objetivo interno para um SLI. "Queremos que 99,9% das requisições tenham latência abaixo de 200ms." O SLO é interno — é o que a equipe se compromete a atingir, que é tipicamente mais exigente que o SLA externo.

SLA (Service Level Agreement): o compromisso contratual externo com o cliente. Geralmente menos exigente que o SLO interno — há uma folga deliberada para que a equipe tenha margem antes de violar o contrato.

A relação é: SLI mede → SLO define o objetivo → SLA é o contrato. Se o SLO interno é 99,95%, o SLA externo pode ser 99,9% — dando margem de manobra.

O conceito de error budget (orçamento de erro) transforma SLO de número estático em ferramenta de gestão.

Se o SLO é 99,9% de disponibilidade mensal, o error budget é 0,1% — ou cerca de 43 minutos de downtime por mês. Esse é o "orçamento" da equipe para indisponibilidade — seja por deploys com problema, por bugs, por manutenção.

Quando o error budget está alto (pouco usado), a equipe pode mover mais rápido — deploy com menos cerimônia, experimentar mudanças mais agressivas. Quando o error budget está baixo ou esgotado, a equipe desacelera: sem deploys de feature até o orçamento se recuperar, foco em estabilidade.

Isso cria um equilíbrio natural entre velocidade de desenvolvimento (que consome error budget) e confiabilidade (que preserva). É a implementação prática de "risco aceitável" em desenvolvimento de software.

SLAs de fornecedores podem ser escritos de forma que parecem generosos mas protegem pouco o contratante. Os pontos de atenção:

Como downtime é calculado: o SLA exclui manutenção planejada? Exclui incidentes causados pelo próprio cliente? Exclui "eventos de força maior" definidos de forma ampla? A disponibilidade efetiva pode ser muito menor do que o número no SLA sugere.

Como disponibilidade é medida: ping do próprio servidor do fornecedor não detecta problemas que afetam clientes externos. Monitoramento independente de múltiplos pontos geográficos é mais representativo.

Penalidades e créditos: o que acontece quando o SLA é violado? Créditos em conta que representam fração do impacto do downtime raramente compensam a perda operacional. Para serviços críticos, verificar se há possibilidade de rescisão por violação recorrente.

Processo de reivindicação: em muitos SLAs, o crédito não é automático — o cliente precisa abrir chamado, provar o downtime e solicitar o crédito dentro de prazo específico. Processos burocráticos que tornam a reivindicação impraticável são uma forma de SLA que existe no papel, não na prática.

SLA é instrumento de gestão de fornecedor, não apenas proteção legal. Para PMEs que dependem de serviços de tecnologia críticos — ERP, e-commerce, sistema de pagamentos — ter SLA claro é o que permite cobrar o fornecedor de forma objetiva quando o serviço falha.

O passo mais importante antes de assinar qualquer contrato de serviço de tecnologia crítico: traduzir o SLA em impacto de negócio. Se o sistema de pedidos ficar 43 minutos indisponível por mês (o que 99,9% permite), qual é o custo? Se esse custo é maior do que a diferença de preço para um plano com 99,99%, a decisão de qual plano contratar fica mais clara.

Para serviços desenvolvidos internamente, a adoção de SLOs formais — mesmo que só a equipe técnica acompanhe — cria accountability sobre confiabilidade que conversa direta não cria. "O sistema ficou fora 4 horas no mês" é informação; "violamos o SLO de 99,9% por 3h17 no mês, o que esgotou 90% do error budget" é gestão.