SLA é Service Level Agreement. O acordo entre o provedor de serviços de TI e o cliente que define o que o serviço vai entregar e com qual qualidade.
Na prática: o SLA responde o que o cliente pode esperar.
O que o SLA define
Um SLA especifica:
Disponibilidade: o serviço estará disponível em qual percentual do tempo. 99,9% significa cerca de 8,7 horas de indisponibilidade por ano.
Tempo de resposta: em quanto tempo a equipe começa a tratar um incidente após o registro.
Tempo de resolução: em quanto tempo o incidente será resolvido.
Prioridade: como os incidentes são classificados por impacto e urgência.
Exclusões: quando o SLA não se aplica. Manutenção programada, eventos fora do controle do provedor.
OLA: o acordo interno
OLA é Operational Level Agreement. Acordo entre o provedor de TI e uma equipe interna da mesma organização.
O SLA faz uma promessa ao cliente. O OLA garante que as equipes internas vão conseguir cumprir essa promessa.
Exemplo: o SLA com o cliente diz que incidentes críticos serão resolvidos em 2 horas. Para isso funcionar, a equipe de infraestrutura e a equipe de aplicações precisam de um OLA entre elas. Infraestrutura restaura o servidor em 1 hora. Aplicações resolvem o problema de software na hora restante.
Sem o OLA, o SLA vira promessa sem base.
UC: o contrato com fornecedores
UC é Underpinning Contract. Contrato com fornecedores externos que suportam a entrega do serviço.
Se o seu SLA com o cliente depende de um link de internet de uma operadora, o contrato com essa operadora é o UC. Ele precisa garantir disponibilidade compatível com o que você prometeu.
A relação é em cascata: UC suporta o OLA. OLA suporta o SLA.
Se o seu UC permite 4 horas de indisponibilidade por mês e o seu SLA promete 99,9% de disponibilidade, o problema está criado antes de qualquer incidente acontecer.
A hierarquia
SLA — com o cliente (externo)
↑ suportado por
OLA — entre equipes internas
↑ suportado por
UC — com fornecedores externos
O que o ITIL 4 critica nos SLAs tradicionais
O ITIL 4 tem um nome para o problema mais comum: watermelon SLA. Verde por fora, vermelho por dentro.
Os indicadores técnicos estão todos dentro do acordado. Uptime: 99,9%. Tempo de resposta: dentro do SLA. Mas o cliente está insatisfeito.
Acontece porque as métricas técnicas não capturam o que importa para o negócio. Uptime do servidor não é o mesmo que experiência do usuário.
Daí o ITIL 4 defende SLAs com métricas orientadas ao negócio. Em vez de só medir disponibilidade do servidor, medir taxa de sucesso nas transações do cliente ou tempo de resposta da página no horário de pico.
O que a prova ITIL 4 Foundation cobra
Definição de SLA, OLA e UC. Quem são as partes de cada acordo: cliente externo, equipes internas, fornecedores. A relação de cascata entre os três. O conceito de watermelon SLA. Como o ITIL 4 diferencia métricas de negócio de métricas técnicas.
FAQ
SLA e contrato são a mesma coisa? Não necessariamente. Um SLA pode ser parte de um contrato legal ou ser um documento interno sem força legal. O que define o SLA é o acordo formal sobre níveis de serviço.
O ITIL 4 ainda usa OLA e UC? A publicação oficial do ITIL 4 removeu OLA e UC como termos formais, reconhecendo que na prática todos são chamados de SLA. A perspectiva muda dependendo de qual lado da relação você está. Mas a prova Foundation ainda pode cobrar os conceitos como referência.
O que acontece quando o SLA é violado? Depende do que foi acordado. Penalidades financeiras, créditos de serviço ou processo formal de revisão. O importante é que a violação gere análise e ação corretiva.
▌ SLA, OLA e UC são temas da prova ITIL 4 Foundation. O simulado do PacketPass cobre todos os domínios com questões calibradas para o exame atual.
Informações baseadas no ITIL 4 Foundation oficial (Axelos/PeopleCert) e IT Process Wiki, verificadas em agosto de 2026.