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.
Encontrar fornecedores de TI no oHub
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.