Sla slo ola diferencas

SLA, SLO e OLA: qual a diferença prática

A diferença está em quem promete o quê e para quem. O SLA é o acordo voltado para fora — entre o provedor de TI e quem consome o serviço. O SLO é a régua interna que a equipe usa para não furar esse acordo. A OLA é o compromisso entre equipes internas para que a operação entregue o que o SLO exige. Os três tratam de "nível de serviço", mas em camadas diferentes da mesma cadeia.

O que é um SLA na prática

O SLA é o acordo de nível de serviço entre o provedor de TI e o cliente. É a promessa formal: o que será entregue, com qual métrica, em qual janela e o que acontece se a meta não for cumprida. Um exemplo típico de SLA interno: "o ERP fica disponível 99,5% do horário comercial; chamados críticos são resolvidos em 4 horas". O traço que define um SLA, e não um SLO, é a consequência: o engenheiro do Google Chris Jones e seus coautores resumem que a forma mais fácil de distinguir os dois é perguntar "o que acontece se a meta não for atingida?" — se há uma consequência explícita (um crédito, uma multa), é um SLA^[1].

O que é um SLO

O SLO é o objetivo de nível de serviço: um valor-alvo (ou faixa de valores) para uma métrica de serviço, perseguido internamente pela equipe. Segundo a obra Site Reliability Engineering, do Google, um SLO é "um valor-alvo ou faixa de valores para um nível de serviço medido por um SLI"^[1]. Ele costuma ser mais rígido que o SLA para criar folga: se você promete 99,5% ao cliente, pode mirar 99,7% por dentro. Essa margem é deliberada — o próprio material do Google recomenda usar um SLO interno mais apertado do que o anunciado ao usuário, justamente para reagir a problemas crônicos antes que eles fiquem visíveis por fora^[1].

O que é uma OLA (acordo de nível operacional)

A OLA é o acordo entre o provedor de TI e outra parte da mesma organização que apoia a entrega do serviço. Na definição do glossário ITIL, uma OLA é "um acordo entre um provedor de serviço de TI e outra parte da mesma organização" que sustenta a entrega ao cliente e define os bens ou serviços a serem providos e as responsabilidades de cada lado^[5]. Exemplo: "o time de redes restaura links em até 2 horas". Sem essa OLA, o time de aplicação não tem como cumprir o SLA de resolução em 4 horas — porque parte do relógio dele depende da rede voltar.

Quem assina o quê, e com quem

A diferença entre os três fica mais clara quando se olha quem está dos dois lados de cada acordo. O SLA é assinado com o cliente (externo ou área de negócio); a OLA, com outro time da mesma empresa; o SLO não é "assinado" com ninguém — é uma meta interna de engenharia.

Há ainda um quarto elo, voltado para fora da organização: o contrato de apoio (underpinning contract, ou UC), firmado com um fornecedor externo. A OLA é interna; o UC é o equivalente com um terceiro. Ambos existem para a mesma finalidade — sustentar o SLA.

Como SLA, SLO e OLA se encadeiam

O SLA externo só é viável se a cadeia interna fechar. A promessa ao cliente (SLA) é sustentada pelas metas internas (SLOs), que por sua vez dependem dos acordos entre times (OLAs) e dos contratos com fornecedores (UCs). Quebrou um elo lá embaixo, a promessa lá em cima não se cumpre — e quem aparece para o cliente é o SLA.

Um exemplo encadeado: o ERP a 99,5%

Suponha que a TI prometa ao negócio um ERP disponível 99,5% no horário comercial, com chamados críticos resolvidos em 4 horas. Esse é o SLA. Para sustentá-lo, a equipe de aplicação mira internamente 99,7% e tempo de resolução de 3 horas — o SLO, com folga proposital. Para o SLO fechar, o time de redes se compromete a restaurar links em 2 horas e o time de banco de dados a responder incidentes em 1 hora: são as OLAs. E como o ERP roda em nuvem, há um UC: o provedor garante um patamar de disponibilidade de infraestrutura. Se a rede demora 3 horas em vez de 2, o SLO de 3 horas estoura, e o SLA de 4 horas fica em risco — tudo por causa de uma OLA que não se cumpriu.

O que é um contrato de apoio (underpinning contract)

O contrato de apoio é o acordo com um fornecedor externo que sustenta o SLA da sua TI. É a versão "para fora" da OLA. Exemplo: o provedor de cloud publica um patamar de disponibilidade para o serviço de computação, e a sua TI depende disso para prometer 99,5% ao negócio. Como referência pública desse tipo de contrato, a AWS mantém SLAs publicados para todos os seus serviços pagos e disponíveis de forma geral — são mais de 300 SLAs separados no site da empresa^[3]. Esses documentos são exatamente os UCs em que a TI se apoia.

Por que assinar SLA sem OLA é o erro mais comum

Porque a conta não fecha quando o incidente acontece. Muitas empresas no Brasil assinam um SLA com fornecedor — ou prometem um SLA ao negócio — sem ter mapeado as OLAs internas que sustentam aquela promessa. No dia a dia parece funcionar; na hora do incidente, descobre-se que o time de redes nunca se comprometeu com prazo nenhum, e o SLA estoura por uma dependência que ninguém formalizou. O SLA é a parte visível; a OLA é a fundação. Assinar a promessa sem a fundação é construir no ar.

SLI, SLO e error budget: a visão de SRE

Antes de definir um SLO, é preciso definir o que se mede — e isso é o SLI. A engenharia de confiabilidade (SRE, Site Reliability Engineering) trata SLA, SLO e SLI como uma hierarquia de medição: o SLI é o indicador, o SLO é a meta sobre esse indicador, e o SLA é o contrato que embute consequências sobre o SLO.

O que é um SLI

O SLI (Service Level Indicator) é uma medida quantitativa cuidadosamente definida de algum aspecto do nível de serviço entregue. Segundo a obra de SRE do Google, exemplos comuns de SLI são a latência de requisições, a taxa de erro (fração das requisições que falham) e a disponibilidade (fração do tempo em que o serviço está utilizável)^[1]. O SLI é a régua; o SLO é a marca na régua que você quer atingir. Não dá para ter SLO sem antes acordar como o SLI é medido — caso contrário, cada lado mede de um jeito e a discussão vira disputa de planilha.

O que é error budget e por que ele muda a conversa

O error budget (orçamento de erro) é a margem de falha tolerada por um SLO — e exigir 100% de disponibilidade é, segundo o material de SRE do Google, "irreal e indesejável"^[1]. Se o SLO é 99,9%, sobra 0,1% de "orçamento" para indisponibilidade dentro do período. Enquanto há orçamento, a equipe pode lançar mudanças com mais liberdade; quando o orçamento se esgota, freia-se o ritmo de mudanças e investe-se em estabilidade. O error budget transforma uma briga ("desenvolvimento quer lançar, operação quer estabilidade") em um número compartilhado que decide a prioridade.

Os "noves" e o custo de cada nove a mais

Cada nove adicional de disponibilidade encurta drasticamente o tempo de indisponibilidade tolerado — e encarece. A obra de SRE do Google registra que a indústria expressa alta disponibilidade pelo número de "noves": 99% são "dois noves", 99,999% são "cinco noves"^[1]. O salto entre eles não é linear. Em um mês de 30 dias, o orçamento de indisponibilidade cai de forma acentuada a cada nove:

Os valores acima são cálculo direto sobre a fração de um mês de 30 dias (43.200 minutos) e de um ano. A leitura prática: prometer 99,99% significa tolerar pouco mais de 4 minutos de queda por mês — um patamar que exige redundância, automação e equipe de plantão. Prometer um nove a mais do que a infraestrutura entrega é o caminho mais curto para quebrar o SLA.

Como definir um SLA realista

Parta do que a infraestrutura entrega hoje, não do número que soa bonito. Um SLA realista nasce da medição do comportamento atual do serviço, da criticidade dele para o negócio e de uma margem de folga (error budget) entre o que se promete e o que se mira por dentro. Meta inalcançável não protege ninguém — só gera quebra e desconfiança.

A anatomia de um bom SLA

Um SLA bem escrito deixa pouca margem para interpretação no dia do incidente. Os elementos que não podem faltar:

1. Serviço coberto: qual sistema ou serviço exatamente, sem ambiguidade.
2. Métrica clara: disponibilidade, tempo de resposta, tempo de resolução — e como cada uma é calculada.
3. Janela de medição: horário comercial? 24x7? Mensal? O número só faz sentido com a janela.
4. Exclusões: manutenção programada, fatores fora do controle do provedor, ações do próprio cliente.
5. Penalidades: o que acontece ao furar — crédito, escalonamento, revisão.
6. Processo de exceção: como uma das partes contesta ou pede revisão de uma medição.

Como um SLA real é estruturado: o exemplo do EC2

Vale ler um SLA público para ver a anatomia funcionando. No SLA do Amazon EC2, a AWS compromete-se a manter um percentual de disponibilidade mensal de pelo menos 99,99% no nível de região (instâncias distribuídas em duas ou mais zonas) e de 99,5% no nível de instância individual^[4]. A consequência é um crédito de serviço escalonado: por exemplo, no nível de região, menos de 99,99% e até 99,0% gera 10% de crédito; abaixo de 95,0%, 100% de crédito^[4]. O contrato define ainda exclusões explícitas (fatores fora do controle razoável da AWS, ações do cliente, problemas no equipamento dele) e como a indisponibilidade é calculada — minutos do mês em que o serviço esteve indisponível^[4]. Cada um desses elementos é parte da anatomia descrita acima.

O efeito do câmbio sobre penalidades e contratos no Brasil

Os créditos de SLA dos grandes provedores de cloud são calculados sobre a fatura, em regra denominada em dólar. No contexto brasileiro, isso significa que tanto o valor de uma penalidade quanto o custo de elevar o patamar de SLA flutuam com o câmbio. Ao definir um SLA interno apoiado em um UC em dólar, vale considerar essa variação — o crédito que o fornecedor paga por uma queda pode não cobrir o prejuízo que a mesma queda causa ao negócio em reais.

Onde a abordagem muda conforme o porte

Erros comuns ao definir SLA, SLO e OLA

A maioria dos problemas de nível de serviço não vem de incidente raro, e sim de acordo mal definido. Os erros se repetem entre empresas e quase todos têm a mesma raiz: prometer sem sustentar.

Os erros que mais derrubam a promessa

• Assinar SLA sem ter OLA por trás: a promessa externa não tem fundação interna e estoura no primeiro incidente que depende de outro time.
• Copiar SLA de outra empresa: o número do concorrente não reflete a sua infraestrutura nem a criticidade dos seus serviços.
• Prometer 99,99% sem infraestrutura para isso: quatro noves toleram pouco mais de 4 minutos de queda por mês e exigem redundância que nem sempre existe.
• Medir diferente do contrato: se o SLA fala em disponibilidade mensal e você mede em horário comercial, a conta nunca bate — e a discussão vira disputa de método.
• Não excluir manutenção programada: sem essa cláusula, toda janela de manutenção conta como indisponibilidade e consome o orçamento à toa.
• Definir SLO igual ao SLA: sem folga entre meta interna e promessa externa, qualquer desvio já é quebra de contrato.

Por que copiar metas de fora não funciona

Porque o SLO precisa nascer do comportamento real do seu serviço. O material de SRE do Google é explícito ao recomendar começar por aquilo que os usuários se importam, não pelo que é fácil de medir, e ao alertar que adotar valores sem reflexão pode prender a equipe a uma meta que só se mantém com esforço heroico^[1]. O número do vizinho pode parecer uma referência segura, mas só a sua medição diz o que a sua infraestrutura entrega.

Como os padrões ITSM ajudam a evitar esses erros

Tratar nível de serviço como disciplina, e não como cláusula isolada, é o que sustenta a consistência. A norma ISO/IEC 20000-1:2018 especifica os requisitos de um sistema de gestão de serviços (SMS), cobrindo o planejamento, o desenho, a transição, a entrega e a melhoria dos serviços para atender aos requisitos acordados^[2]. Usar a norma como mapa — não necessariamente certificar a empresa — ajuda a garantir que SLA, SLO e OLA façam parte de um processo contínuo de medição e revisão, em vez de viverem soltos em contratos esquecidos na gaveta.