O que é OLA? Entenda o Operational Level Agreement e como ele garante a qualidade interna dos serviços de TI
Quando uma empresa firma um SLA com o cliente — prometendo, por exemplo, resolver incidentes críticos em até 4 horas — essa promessa depende de acordos internos entre as áreas de TI que raramente aparecem no contrato oficial. É aqui que entra o OLA, o Operational Level Agreement: o acordo que define como as equipes internas se comprometem entre si para garantir que o SLA externo seja cumprido.
Neste guia você vai entender o que é OLA, como ele se diferencia do SLA e do UC, quais são seus componentes essenciais, exemplos práticos e como implementá-lo na sua empresa.
- O que é: Operational Level Agreement — acordo interno entre equipes ou departamentos de TI que define responsabilidades, prazos e métricas para suportar o cumprimento do SLA externo.
- Para que serve: alinhar expectativas entre times internos (service desk, infraestrutura, segurança, banco de dados) para que o serviço entregue ao cliente seja consistente.
- Diferença do SLA: SLA é com o cliente; OLA é interno, entre as equipes que fazem o serviço acontecer.
- Framework: conceito central do ITIL (Information Technology Infrastructure Library).
O que é OLA (Operational Level Agreement)?
O OLA é um acordo formal entre duas ou mais equipes internas de TI de uma organização, que define metas de nível de serviço operacional necessárias para suportar o SLA acordado com o cliente ou usuário final. Enquanto o SLA é a promessa feita para fora, o OLA é a engrenagem interna que torna essa promessa possível.
O conceito é parte central do ITIL (Information Technology Infrastructure Library), o framework de boas práticas para gestão de serviços de TI mais adotado no mundo. No ITIL, o OLA é um dos três tipos de acordos de nível de serviço — ao lado do SLA (com o cliente) e do UC, Underpinning Contract (com fornecedores externos).
A diferença entre SLA, OLA e UC
| Acordo | Entre quem? | Foco | Exemplo |
|---|---|---|---|
| SLA (Service Level Agreement) | Provedor de serviço ↔ Cliente | O que o cliente vai receber | “Incidentes críticos resolvidos em 4h” |
| OLA (Operational Level Agreement) | Equipes internas entre si | Como as equipes se suportam internamente | “Infraestrutura restaura servidor em 1h para o service desk resolver em 4h” |
| UC (Underpinning Contract) | Provedor ↔ Fornecedor externo | O que o fornecedor garante | “Datacenter garante 99,9% de uptime ao provedor” |
A lógica é em cascata: o UC suporta o OLA, o OLA suporta o SLA. Se o fornecedor externo não cumpre o UC, a equipe interna não consegue cumprir o OLA, e o SLA com o cliente é violado.
Componentes essenciais de um OLA
1. Escopo do serviço
Quais atividades, sistemas ou processos são cobertos por este OLA. Define claramente o que está incluído e o que está fora do escopo.
2. Partes envolvidas
Quais equipes ou departamentos estão comprometidos — service desk, infraestrutura, segurança, banco de dados, desenvolvimento, etc.
3. Metas e métricas
Os indicadores mensuráveis que cada equipe deve cumprir: tempo de resposta, tempo de resolução, disponibilidade de sistemas, taxa de erro, etc.
4. Responsabilidades
O que cada equipe deve fazer especificamente. Evita a zona cinzenta do “achei que era o outro time que resolvia isso”.
5. Processo de escalonamento
O que acontece quando uma meta não é cumprida — quem é notificado, em quanto tempo, e qual a cadeia de escalonamento.
6. Revisão e validade
Frequência de revisão do OLA (trimestral, semestral) e prazo de validade do acordo.
Exemplo prático de OLA em uma empresa de TI
Imagine uma empresa de suporte de TI com SLA de 4 horas para incidentes críticos. Para cumprir esse SLA, os OLAs internos poderiam ser:
- Service Desk → Infraestrutura: quando o service desk abre um chamado crítico de servidor fora do ar, a equipe de infraestrutura tem 1 hora para iniciar o diagnóstico e 3 horas para restabelecer o serviço.
- Service Desk → Segurança: para incidentes classificados como violação de segurança, a equipe de segurança deve ser notificada em até 30 minutos e responder com análise preliminar em 1 hora.
- Infraestrutura → Banco de Dados: quando um restore de banco de dados é necessário para resolver um incidente crítico, a equipe de DBA tem 2 horas para executar o procedimento.
Cada OLA foi calibrado para que, somados, os tempos internos não ultrapassem as 4 horas prometidas no SLA.
Como implementar OLAs na sua empresa
1. Mapeie os serviços e as dependências
Liste os serviços cobertos pelos seus SLAs e identifique quais equipes internas participam de cada serviço. Use um CMDB ou mapa de dependências de serviços para visualizar as relações.
2. Envolva as equipes desde o início
OLAs impostos de cima para baixo costumam falhar. As metas precisam ser negociadas com as equipes que vão cumpri-las — elas conhecem melhor suas capacidades reais e gargalos.
3. Defina métricas mensuráveis
Evite metas vagas como “responder rapidamente”. Use números: “responder em até 30 minutos”, “restaurar disponibilidade em até 2 horas”, “taxa de falha abaixo de 0,1%”.
4. Integre ao seu sistema de chamados
Ferramentas como ServiceNow, Jira Service Management ou GLPI permitem configurar SLAs e OLAs diretamente nos chamados, com alertas automáticos quando os prazos estão próximos de vencer.
5. Revise periodicamente
OLAs desatualizados são pior do que não ter OLA — criam uma falsa sensação de controle. Revise ao menos trimestralmente e após qualquer mudança significativa na infraestrutura ou na equipe.
Benefícios do OLA bem implementado
- Clareza de responsabilidades: cada equipe sabe exatamente o que deve entregar e em quanto tempo.
- Redução de conflitos internos: menos “isso não é comigo” porque o escopo está documentado.
- SLAs mais confiáveis: quando as engrenagens internas funcionam, a promessa ao cliente é cumprida de forma consistente.
- Melhoria contínua: métricas documentadas permitem identificar quais equipes são gargalo recorrente e focar os esforços de melhoria.
- Base para auditoria: fundamental para certificações como ISO 20000 e para auditorias de qualidade de serviço de TI.
Perguntas frequentes sobre OLA
OLA é obrigatório para ter ITIL?
O ITIL é um conjunto de boas práticas, não uma certificação obrigatória de processo. Mas para organizações que implementam ITIL de forma séria — especialmente as que buscam certificação ISO 20000 — o OLA é um componente esperado e avaliado. Empresas que apenas “conhecem” o ITIL sem formalizar OLAs costumam ter lacunas sérias na gestão de incidentes e problemas.
OLA serve para empresas pequenas?
Sim, mas o grau de formalidade deve ser proporcional ao tamanho. Em uma equipe pequena de TI, um OLA pode ser um documento simples de uma página que define quem faz o quê e em quanto tempo. O importante é que as responsabilidades estejam claras — não o volume de papelada.
Qual a diferença entre OLA e KPI de TI?
KPIs são indicadores de desempenho que medem resultados — taxa de resolução no primeiro contato, disponibilidade dos sistemas, MTTR. O OLA usa KPIs como critérios de cumprimento do acordo. Um OLA bem elaborado especifica quais KPIs cada equipe deve atingir, transformando indicadores em compromissos formais.
O que acontece quando um OLA é descumprido?
Depende do que foi acordado no próprio OLA. O mais comum é o escalonamento automático para gestores, abertura de análise de causa raiz (seguindo o MASP ou processo similar) e registro do desvio para fins de melhoria contínua. Ao contrário do SLA, o descumprimento do OLA geralmente não gera penalidades financeiras — mas impacta métricas de performance das equipes.
Ferramentas para gerenciar OLAs
ServiceNow e Jira Service Management são as mais completas e permitem configurar OLAs com alertas automáticos. Para empresas menores, GLPI (gratuito e open source) ou Freshservice são alternativas viáveis. O Excel ainda é usado em muitas organizações — funciona para equipes pequenas, mas escala mal.
Conclusão
O OLA é o elo que falta em muitas operações de TI que prometem SLAs ao cliente mas não têm clareza interna sobre quem faz o quê para cumprir essa promessa. Implementá-lo corretamente — com metas negociadas, métricas mensuráveis e revisão periódica — transforma o SLA de uma promessa de esperança em um compromisso sustentável.
Se você está estruturando ou melhorando a gestão de serviços de TI da sua empresa, confira mais conteúdos sobre gestão e processos no Atraca.
Comentários