Como este tema funciona na sua empresa
Sem SLA formal. Expectativas implícitas ("sistema deve estar sempre disponível"). Solução: começar com SLO simples (ex: 99% uptime), comunicar expectativa clara ao fornecedor. Sem complexidade de SLA legal, apenas acordo de entendimento prático.
Tem SLA com alguns clientes, pode estar desatualizado. Solução: estruturar SLA por tipo de sistema (core, suporte, infra com SLOs diferentes). Monitorar SLI automaticamente. Comunicar SLA a stakeholders internos.
SLA complexo, múltiplos clientes, múltiplas regiões, diferentes SLOs por cliente/serviço. Plataforma de SLA management automática. SLI medidos em tempo real. Error budgets para guiar decisões de desenvolvimento vs. confiabilidade.
SLA (Service Level Agreement) é contrato (com cliente ou interno) que especifica nível de serviço esperado. SLO (Service Level Objective) é meta interna para atingir SLA. SLI (Service Level Indicator) é métrica técnica que indica se SLO foi atingido. Simplificando: SLA = promessa, SLO = meta interna, SLI = medida técnica.
Diferenciação clara: SLA vs. SLO vs. SLI
A confusão entre esses três termos é comum até entre profissionais de TI. Exemplificar:
Cenário: Empresa contrata SaaS para email. Contrato diz: "99.9% uptime de email".
- SLA: "99.9% uptime de email" — promessa legal com o cliente, pode ter penalidade se quebrada
- SLO interno do fornecedor: "99.95% uptime" — meta interna mais rigorosa que SLA (buffer de segurança). Se fornecedor cumpre SLO, certamente cumpre SLA.
- SLI medido: Uptime real monitorado (99.87% em janeiro, 99.92% em fevereiro). É a métrica técnica que indica se SLO foi atingido.
Componentes de um SLA bem estruturado
- Escopo: Quais sistemas/serviços estão cobertos? (ex: email, cloud storage, não backup)
- Disponibilidade: Uptime esperado (99%, 99.5%, 99.9%, etc.)
- Latência: Response time aceitável (ex: < 100ms para 95% das requisições)
- Suporte: Horário, tempo de resposta por severidade, como contatar
- Exclusões: O que não é responsabilidade do fornecedor (DDoS, cliente incompetência)
- Medição: Como medir uptime? Ferramentas? Frequência de reporte?
- Penalidades: Crédito de serviço se quebra SLA (ex: 10% de crédito se < 99%)
SLO interno: como definir para cobrir SLA
SLA é promessa externa (com cliente). SLO é meta interna (para seu time). SLO deve ser mais rigoroso que SLA para gerar buffer.
Exemplo prático:
- SLA com cliente: 99.5% uptime de API
- SLO interno do time: 99.8% uptime. Se team atinge 99.8%, garante que SLA de 99.5% será atingido mesmo com variações naturais.
- SLI medido: 99.76% (dentro de SLO, portanto dentro de SLA)
SLI (Service Level Indicator): como medir e automatizar
SLI é a medida técnica. Exemplos por tipo de serviço:
- Disponibilidade (uptime): Ping a cada 5 min, conta downtime total / tempo total * 100
- Latência: Response time de requisição (ex: 95% das requisições < 100ms)
- Taxa de erro: % de requisições que retornam erro (ex: < 0.1%)
- Throughput: Requisições por segundo (ex: mínimo 1000 req/s)
Automação: ferramentas de APM (Datadog, New Relic, Dynatrace) medem SLI em tempo real, calculam SLA/SLO automático, alertam se tendência é quebrada.
Error Budget: gastar confiabilidade inteligentemente
Conceito avançado: se SLO é 99.9% uptime (permitido 43 min downtime/mês), team tem "error budget" de 43 minutos. Podem usá-lo para:
- Deploy sem downtime zero (risco controlado)
- Experimento em produção (A/B test que pode falhar)
- Manutenção que pode causar error rate temporal
Se error budget ainda está disponível, é seguro fazer. Se já foi consumido, deve esperar ou priorizar confiabilidade.
Sinais de que sua empresa precisa estruturar SLA/SLO/SLI
- Empresa oferta serviço (SaaS, API, platform) sem SLA definido com clientes
- Time de desenvolvimento não sabe quanto "pode quebrar" sem violar SLA
- Não há métrica de confiabilidade sendo monitorada em tempo real
- Disputa frequente com cliente sobre "quanto tempo sistema ficou down"
- SLA definido, mas ninguém sabe como mede ou se está sendo cumprido
Caminhos para estruturar SLA/SLO/SLI
Viável se tem SRE/DevOps com experiência em confiabilidade e monitoramento.
- Perfil: SRE, DevOps lead, ou eng. senior com experience em observabilidade
- Tempo: 4–8 semanas para definir SLOs, implementar medição de SLI, comunicar SLAs
- Risco: SLO muito ambicioso (100% impossível) ou muito relaxado (sem valor)
Recomendado se precisa de framework SLA/SRE implementado rapidamente.
- Tipo: Consultoria SRE / Google Cloud SRE certified
- Vantagem: Baseado em best practices (Google SRE Book), SLOs realistas, automação
- Resultado: SLA/SLO/SLI definido, ferramentas de monitoramento configuradas, plano de error budget
Precisa estruturar SLA/SLO/SLI para seu serviço?
Se a empresa oferece serviço e quer definir SLAs realistas baseadas em best practices SRE, o oHub conecta você com consultores SRE especializados. Em menos de 3 minutos, descreva seu serviço e receba propostas, sem compromisso.
Solicitar orçamento de Gestão de TI Solicitar orçamento de Serviços na Nuvem Solicitar orçamento de Consultoria de TI
Confira no oHub as empresas da nossa rede nas categorias: Gestão de TI, Serviços na Nuvem e Consultoria de TI
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é a diferença entre SLA, SLO e SLI?
SLA é contrato/promessa (com cliente ou interno). SLO é meta interna (mais rigorosa que SLA). SLI é métrica técnica que indica se SLO foi atingido. Simplificando: SLA = promessa, SLO = meta, SLI = medida.
Como definir SLA/SLO para meus serviços?
Começar com componentes: escopo (quais sistemas?), disponibilidade (99%? 99.9%?), latência (response time?), suporte (horário? resposta?), penalidades (crédito se quebra?). SLO deve ser 0.1–0.5% mais rigoroso que SLA para buffer.
O que incluir em um SLA?
Escopo (sistemas cobertos), disponibilidade (uptime %), latência (response time), suporte (horário, severidade), exclusões (o que não cobre), medição (como mede?), penalidades (crédito de serviço se quebra).
Como medir SLI?
Use APM tool (Datadog, New Relic, Prometheus): meça uptime (ping), latência (responde em X ms?), taxa de erro (% de 5xx), throughput (requisições/seg). SLI = métrica técnica agregada que indica confiabilidade real.
Como estruturar penalidades em SLA?
Comum: crédito de serviço (ex: 10% se < 99%, 25% se < 99.5%). Raro: multa em dinheiro (muito punitivo). Refund ou crédito é mais prático e justo para ambas as partes.