NexTool Solutions

Configurar SLA e OLA no GLPI é a parte fácil - o que quebra na operação real é a escalação que nunca dispara. Na sustentação de ambientes GLPI de clientes, o pedido que mais chega não é "como crio um SLA", e sim "criei tudo e ninguém é avisado quando o prazo estoura". Este guia configura SLA e OLA no GLPI 11 do zero e mostra as consultas SQL que usamos para diagnosticar por que os prazos não notificam.

SLA vs OLA: o que muda na prática

SLA (Service Level Agreement) é o acordo com o cliente (interno ou externo): define o compromisso de tempo de resposta e de resolução. Exemplo: "chamados de prioridade alta são respondidos em 1h e resolvidos em 4h".

OLA (Operational Level Agreement) é o acordo interno entre as equipes que sustentam aquele SLA. Exemplo: "a infraestrutura responde escalonamentos do N1 em até 30 minutos". No GLPI, o SLA grava os prazos em time_to_own e time_to_resolve do chamado; o OLA grava em internal_time_to_own e internal_time_to_resolve. Os dois correm em paralelo - e aqui mora a primeira confusão: escalar para o N2 NÃO pausa o SLA do cliente.

Como o GLPI modela SLA e OLA por dentro

Entender o modelo de dados evita a maioria dos erros de configuração. No GLPI, SLA e OLA não são objetos soltos: vivem dentro de um SLM (Service Level), e é o SLM que carrega o calendário.

• SLM (glpi_slms): o guarda-chuva. Tem o calendars_id - ou seja, o calendário pertence ao SLM, não a cada SLA.
• SLA (glpi_slas) e OLA (glpi_olas): cada linha é um prazo, com type (TTO ou TTR), number_time e definition_time (minute / hour / day).
• Níveis de escalação (glpi_slalevels / glpi_olalevels): as ações disparadas em X% do prazo.

Dois conceitos que costumam confundir quem vem de outra ferramenta:

TTO - Time to Own (tempo de resposta)

Prazo até o chamado ser "levado em conta" (assumido por um técnico). Atenção: o TTO não fecha quando alguém apenas abre o chamado na tela; fecha quando ocorre a primeira atribuição ou o primeiro acompanhamento - é o que o GLPI grava em takeintoaccount_delay_stat.

TTR - Time to Resolve (tempo de resolução)

Prazo até a solução do chamado.

Passo a passo: configurar SLA no GLPI 11

1. Calendário primeiro. Antes do SLA, defina o calendário de atendimento (Configuração > Calendários) com os segmentos de expediente reais (ex.: seg-sex, 08:00-18:00). Se o SLM ficar sem calendário (calendars_id = 0), o GLPI conta 24h corridas; com calendário, conta só horas úteis.
2. Crie o SLM e associe o calendário. É o container que agrupa os SLAs e OLAs do serviço.
3. Crie um SLA por prioridade, um para TTO e outro para TTR. Use a matriz abaixo como ponto de partida.
4. Atribua via regra de negócio (Administração > Regras > Regras de negócio para chamados): critério Prioridade = Alta, ação "Atribuir SLA (TTR)" e "Atribuir SLA (TTO)". O SLA é aplicado na criação; se a prioridade mudar depois, é preciso uma regra que recalcule.
5. Configure os níveis de escalação em cada SLA (ações em 75%, 100% e 150% do prazo).

São faixas honestas de referência inicial: recalibre após 60-90 dias com os números reais do seu Service Desk e nunca copie os prazos de outro cliente.

Configurar OLA

O OLA segue a mesma estrutura (TTO/TTR mais níveis de escalação), mas mede o compromisso interno entre equipes. O cenário típico: quando o N1 escala para o N2, o OLA do N2 começa a contar - e o GLPI grava esses prazos em internal_time_to_own e internal_time_to_resolve, separados do SLA do cliente. Repetindo o ponto que mais gera dúvida: o OLA não congela o SLA.

O erro comum: a escalação que nunca dispara

Na sustentação, o chamado recorrente sobre SLA não é de configuração - é "o prazo estourou e ninguém foi avisado". Em quase todos os casos a causa é a mesma: a ação automática slaticket, que varre os níveis de escalação, está em modo interno (só roda quando alguém navega no GLPI) ou o GLPI cron externo não está ativo. O nível existe, o prazo está gravado em time_to_resolve, mas nada dispara aos 75% porque o processo que lê os níveis nunca executa. Por isso, no nosso checklist de implantação, verificar o slaticket vem ANTES de criar qualquer nível de escalação.

Garanta o GLPI cron rodando em modo externo:

# /etc/cron.d/glpi - executa as ações automáticas do GLPI (inclui o slaticket)
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Depois, confirme no banco que a ação está viva e em modo externo:

-- Estado da ação automática de escalação de SLA.
-- mode:  1 = interno (ruim, depende de navegação), 2 = externo (correto)
-- state: 1 = aguardando, 2 = rodando, 0 = desabilitado
SELECT name, state, mode, lastrun, frequency
FROM glpi_crontasks
WHERE name = 'slaticket';

E a consulta que roda no dia a dia da sustentação: chamados com prazo de resolução já estourado e ainda abertos.

-- Chamados com TTR vencido e ainda não solucionados.
-- status: 5 = solucionado, 6 = fechado (excluídos)
SELECT t.id, t.name, t.time_to_resolve, t.status
FROM glpi_tickets t
WHERE t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()
  AND t.status NOT IN (5, 6)
  AND t.solvedate IS NULL
ORDER BY t.time_to_resolve ASC;

Para auditar a configuração (e pegar o SLM sem calendário antes que ele quebre os prazos):

-- SLAs configurados e o calendário herdado do SLM.
-- calendario NULL/vazio = contagem 24h corridas (armadilha clássica).
SELECT s.name AS sla,
       CASE s.type WHEN 1 THEN 'TTO' WHEN 0 THEN 'TTR' END AS tipo,
       s.number_time, s.definition_time,
       cal.name AS calendario
FROM glpi_slas s
JOIN glpi_slms slm ON slm.id = s.slms_id
LEFT JOIN glpi_calendars cal ON cal.id = slm.calendars_id
ORDER BY s.name;

Boas práticas de quem opera

• Comece com 3-5 níveis e recalibre após 60-90 dias com dados reais.
• Calendário realista: não configure 24x7 se a equipe atende em horário comercial - senão o prazo "corre" de madrugada e o chamado nasce estourado.
• Alerte antes da violação (75%) para dar tempo de reação, não só na violação.
• Nunca edite status ou prazos em massa via SQL: você burla o recálculo do tempo de espera (sla_waiting_duration) e o prazo fica errado.
• Documente qual regra de negócio atribui cada SLA - regra órfã é a segunda maior causa de "SLA não aplicado".

Próximo passo

Com SLA e OLA no ar, monte o catálogo de serviços e acompanhe os KPIs do Service Desk para saber se os prazos são realistas.

Se a operação já cresceu e o SLA vira discussão toda semana, a sustentação de GLPI da NexTool assume a configuração, o cron e o monitoramento dos prazos para você.

Revisado pela equipe NexTool Solutions.