Como este tema funciona na sua empresa
Raramente têm SLA interno estruturado. Times são multidisciplinares, papéis fluidos. Desafio: falta de definição de responsabilidades por serviço. Abordagem: começar com SLA simples (uptime, tempo de resposta) para 2-3 serviços críticos internamente, ANTES de exigir fornecedor. Exemplo: "infraestrutura tem SLA interno de 99,95%, então podemos comprometer 99,9% externamente".
Começam separar infraestrutura (interna) de aplicações (interna + fornecedor). SLA interno existe para alguns times. Desafio: inconsistência entre SLAs internos e exigências ao fornecedor. Abordagem: definir SLA por camada (infraestrutura 99,95%, suporte 99,9%, aplicações 99,5%), depois mapear cascata para fornecedor (fornecedor precisa ser melhor).
SLA interno bem estruturado por centro de custo e serviço. Cascata clara para fornecedor. Desafio: orquestração de múltiplas cadeias de SLA. Abordagem: framework de SLA/OLA com dashboard centralizado, revisões trimestrais, ajustes dinâmicos. Cada SLA externo mapeia para 2-3 OLAs internas.
SLA interno (OLA) é acordo entre times internos (ex: suporte e infraestrutura) para suportar um SLA externo. ITIL chama de OLA (Operational Level Agreement). Diferença fundamental: SLA externo é para cliente/contrato; OLA interno é para alinhamento de times. Ambos são importantes: OLA é fundação que permite cumprir SLA[1].
Diferenças entre SLA interno e SLA externo
Formalidade: SLA interno pode começar como memorando (ITIL chama de OLA); SLA externo precisa ser contrato assinado. Penalidades: SLA interno pode ter impacto em bônus/avaliação de time; SLA externo gera penalidades financeiras (desconto em fatura). Renegociação: SLA interno pode ser ajustado trimestralmente; SLA externo é mais estável (renegociações anuais/bienais). Cascata: SLA externo (ex: 99,9%) requer SLA interno mais rigoroso (ex: 99,95%) para gerar margem de segurança. Medição: SLA interno pode incluir métricas operacionais (tempo para aprovação, ciclo de mudança); SLA externo é tipicamente técnico (uptime, latência).
Margem de segurança: SLA interno deve ser 5-10% melhor que externo
Exemplo: cliente requer SLA 99,9% (8.76h downtime/ano). Internamente, infraestrutura deve garantir 99,95% (4.38h downtime/ano). Por quê? Porque há variabilidade. Margem de 5% absorve: (1) Falhas transitórias (problema se resolve sozinho em 10 min, usuário não percebe). (2) Falhas parciais (parte do sistema cai, 50% de usuários afetados; SLA conta de forma diferente). (3) Erro humano (técnico faz mudança errada, leva 30 min para reverter). Com margem, chance de violar SLA externo é baixa (<5%). Sem margem, qualquer problema pequeno viola SLA. Pesquisa Uptime Institute: margem de segurança recomendada é 5% (SLA 99,9% ? OLA 99,95%), validada em múltiplas organizações.
Cascata de responsabilidades: SLA externo ? OLA internas
SLA externo impõe OLA internas que, por sua vez, impõem UCs com fornecedores. Exemplo: Cliente requer 99,9% disponibilidade de aplicação X. Isso depende: (1) Infraestrutura de rede (99,95% OLA). (2) Servidor de aplicação (99,95% OLA). (3) Banco de dados (99,95% OLA). (4) Suporte (resolver incidente em 1h = tempo de resposta OLA). Cada OLA é entre times ou com fornecedor. Se todas as OLAs são cumpridas, SLA externo é cumprido. Se uma OLA falha, SLA pode falhar (cascata). Cada equipe precisa saber: "se eu falho, cliente sofre".
OLA simples (memorando): infraestrutura se compromete com 99,95% uptime. Suporte se compromete com resposta em 30 min. Abordagem: UM email listando compromissos, assinado por ambos. Sem sistema de rastreamento (apenas acompanhamento manual). Revisão: conforme necessidade (quando houver problema). Custo: zero (apenas comunicação).
OLA formal (documento): por função (infraestrutura, suporte, aplicação). Métricas claras (uptime%, tempo de resposta, disponibilidade percebida). Assinado por ambas as partes (gerentes). Rastreamento: dashboard simples (planilha) com cumprimento de OLA por mês. Revisão: trimestral. Ação: se OLA não está sendo cumprido, reunião para discutir aumento de recursos ou ajuste de expectativa.
Framework de SLA/OLA integrado: cada SLA externo mapeia para 2-3 OLAs internas. Sistema de rastreamento automatizado (ITSM, Splice Machine). Dashboard centralizado mostra cascata: SLA externo 99,9% ? OLA1 99,95% + OLA2 99,95%. Se uma OLA está em risco, alerta automático. Revisão: trimestral formal com ajustes. Integração com bonificação de gerentes (se OLA é cumprida, bônus).
Comunicação de OLA: évitar "policiamento" de times
Risco: OLA é comunicado como "vamos cobrar se você falhar" = times se sentem policiados, moral cai. Alternativa: "OLA é suporte mútuo. Se eu não consigo manter OLA, é porque preciso de ajuda. Vamos resolver junto." Tom importante. OLA não é punição. É alinhamento. Se time não consegue cumprir OLA, conversa é: "qual é o bloqueio? Precisamos de mais pessoas? Ferramentas? Treinamento?" Assim, OLA vira ferramenta de melhoria, não de culpa. Times que recebem feedback construtivo via OLA melhoram mais rápido que times que recebem ameaça.
Integração de métricas: SLA externo pode depender de múltiplas OLAs
Exemplo: Tempo de resolução de ticket = "SLA externo é 4h". Isso depende: (1) Tempo de resposta do suporte (0-15 min OLA). (2) Diagnóstico (15-60 min OLA infraestrutura). (3) Resolução (0-180 min OLA de quem for responsável). Total: 4h SLA externo depende de 3 OLAs internas trabalhando juntas. Se qualquer uma falha, SLA falha. Comunicação é crítica: cada time precisa saber seu papel. Dashboard mostra: "incidente X: resposta 10 min (OK), diagnóstico 45 min (OK), resolução 2h (OK). Total 2h55min, SLA 4h cumprido".
Sinais de que você precisa implementar OLA interno
Se você reconhece dois ou mais, implemente OLA agora.
- SLA externo é 99,9%, mas você não sabe o que internamente precisa ser para garantir
- Times internos não sabem qual é responsabilidade deles no SLA com cliente
- SLA externo é frequentemente violado, mas culpa fica "perdida" entre times
- Não há acordo formal de SLA entre times internos
- Improviso: quando SLA está em risco, todos ficam em pânico (sem processo claro)
- Fornecedor de suporte diz "não é problema nosso" enquanto infraestrutura diz "não é nosso"
- Bônus de gerentes não está atrelado a cumprimento de SLA/OLA
Caminhos para implementar OLA interno
Sua equipe define OLA internamente usando template.
- Perfil necessário: gestor de TI + representante de cada time
- Tempo estimado: 2-4 semanas
- Faz sentido quando: você tem tempo, times são cooperativas
- Risco principal: OLA mal calibrado (muito rígido ou flexível demais)
Consultores de ITIL implementam framework SLA/OLA.
- Tipo de fornecedor: consultores de ITIL, transformação de TI
- Vantagem: framework validado, melhor prática, documentação profissional
- Faz sentido quando: você quer qualidade de implementação, múltiplas OLAs
- Resultado típico: cumprimento de SLA 90%+ vs. 50% antes
Quer implementar OLA interno para suportar SLA externo?
O oHub conecta você gratuitamente a consultores ITIL e especialistas em gestão de TI que podem ajudar. Descreva sua situação (SLAs atuais, desafios) em menos de 3 minutos, receba propostas sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. OLA bem estruturado melhora cumprimento de SLA externo dramaticamente.
Perguntas frequentes
OLA é a mesma coisa que SLA interno?
Na prática, sim (usados intercambiavelmente). Tecnicamente, ITIL usa "OLA" (Operational Level Agreement), mas muitos gestores brasileiros dizem "SLA interno". Não há diferença essencial. OLA/SLA interno = acordo com times internos. SLA = acordo com cliente externo.
SLA externo é 99,9%. Qual deveria ser OLA interno?
Regra: 5-10% melhor. SLA 99,9% (8.76h downtime/ano) ? OLA 99,95% (4.38h) ou até 99,99% (52 min) se quer margem grande. Exemplo: SLA 99,9%, OLA 99,95% = margem de 4.38h de "folga" (proteção contra variabilidade).
Como fazer cascata de múltiplas OLAs se uma falha?
Cada time sabe seu papel: "se eu não cumpro OLA, cliente sofre". Documento claro: SLA 4h = resposta 15 min (OLA1) + diagnóstico 60 min (OLA2) + resolução 165 min (OLA3). Se OLA1 ou 2 falha, resto do tempo é insuficiente = SLA falha. Comunicação é crítica.
OLA pode ser renegociado mais frequente que SLA?
Sim. OLA é interno, flexível. Trimestral é comum. SLA é externo, estável (anual/bienal). Essa flexibilidade permite ajustar OLA conforme realidade (mais carga, menos recursos) sem afetar promessa ao cliente.
Como cobrar OLA se time não cumpre? Penalidade?
Não é penalidade (evitar conflito). Abordagem: "qual foi o bloqueio? Vamos ajudar". Se padrão é não-cumprimento, discussão maior: "precisamos de mais recursos? Ferramentas? Treinamento? Ou OLA é inalcançável?". Encontre raiz, não punia.
Fornecedor pode ser parte de OLA interna?
Sim. Se fornecedor fornece infraestrutura, ele é parte da cascata: SLA 99,9% ? OLA infraestrutura (que depende de UC com fornecedor 99,95%). Comunicação clara: fornecedor sabe que falha dele afeta seu SLA com cliente.