O que é OLA?

O OLA (Operational Level Agreement, ou Acordo de Nível Operacional) é o acordo interno entre equipes de uma mesma organização que sustenta, por dentro, a promessa que o SLA faz ao cliente lá fora. Sem OLA, o SLA vira um compromisso sem lastro: cada time supõe que a responsabilidade é do outro e o prazo prometido escorre nas passagens de bastão internas.

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. O OLA é justamente esse acordo interno. Veja como cada peça se encaixa:

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 as 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.

Vale separar o OLA de outros termos vizinhos. O SLA é o contrato externo, com nível de serviço garantido e, em geral, penalidade. O SLO é a meta interna que o provedor persegue, e o SLI é o indicador que mede se ela foi atingida. O OLA é diferente de todos eles: não é meta nem indicador, e sim um acordo entre times internos que se comprometem uns com os outros para que o SLA seja cumprido.

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 acordo 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

A diferença essencial entre os três está em quem assina cada acordo e no que acontece quando ele é descumprido:

A lógica é em cascata: o UC sustenta o OLA, e o OLA sustenta o SLA. Um exemplo concreto amarra os três: o SLA promete ao cliente "incidentes críticos resolvidos em 4h"; para isso, a infraestrutura assume no OLA "restaurar o servidor em 1h para o service desk resolver em 4h"; e, por baixo, o datacenter garante no UC "99,9% de uptime ao provedor". 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 fica de fora.

2. Partes envolvidas

Quais equipes ou departamentos estão comprometidos — service desk, infraestrutura, segurança, banco de dados, desenvolvimento, e assim por diante.

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, entre outros.

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.

Regra prática: os OLAs devem ser mais restritivos que o SLA. Se o SLA diz 4 horas, os OLAs internos devem garantir o resultado em 3 horas — a hora restante é o buffer para imprevistos de comunicação, escalonamento e formalização da resolução.

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 um. Um CMDB ou mapa de dependências de serviços ajuda a visualizar essas 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 seus gargalos.

3. Defina métricas mensuráveis

Evite metas vagas como "responder rapidamente". Use números: "responder em até 30 minutos", "restaurar a disponibilidade em até 2 horas", "taxa de falha abaixo de 0,1%".

4. Integre ao seu sistema de chamados

Ferramentas de ITSM como ServiceNow, Jira Service Management ou GLPI permitem configurar SLAs e OLAs diretamente nos chamados, com alertas automáticos quando os prazos estão perto de vencer.

5. Revise periodicamente

OLAs desatualizados são piores 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 concentrar os esforços de melhoria.
• Base para auditoria: fundamental para certificações como a ISO/IEC 20000 e para auditorias de qualidade de serviço de TI.

Perguntas frequentes sobre OLA

Qual a diferença entre SLA e OLA?

O SLA é o acordo externo entre o provedor de TI e o cliente final, com níveis de serviço garantidos e, em geral, penalidade contratual em caso de descumprimento. O OLA é o acordo interno entre as equipes de TI que viabilizam esse SLA (por exemplo, service desk e infraestrutura). Um olha para fora, para o cliente; o outro olha para dentro, para os times que fazem o serviço acontecer.

O OLA faz parte do ITIL? É obrigatório?

Sim, o OLA é um conceito central do ITIL, dentro da Gestão de Nível de Serviço. O ITIL é um conjunto de boas práticas, não uma regra obrigatória, mas recomenda que cada SLA seja sustentado por OLAs internos e por UCs com fornecedores externos. Organizações que buscam certificação ISO/IEC 20000 costumam ter os OLAs formalizados e avaliados.

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, a abertura de análise de causa raiz (seguindo o MASP ou processo similar) e o registro do desvio para fins de melhoria contínua. Ao contrário do SLA, o descumprimento do OLA em geral não gera penalidade financeira, mas impacta as métricas de performance das equipes internas.

Qual a diferença entre OLA e KPI de TI?

KPIs são indicadores que medem resultados, como taxa de resolução no primeiro contato, disponibilidade dos sistemas ou MTTR. O OLA usa KPIs como critérios de cumprimento do acordo: ele especifica quais indicadores cada equipe precisa atingir, transformando métricas soltas em compromissos formais entre os times.

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 que importa é que as responsabilidades estejam claras, não o volume de papelada.

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, comece mapeando um único SLA e desenhando os OLAs que o sustentam. Para aprofundar, vale consultar a definição de Operational-level agreement na Wikipedia ou explorar mais conteúdos sobre gestão e processos no Atraca.