NexTool Solutions

Configurar SLA e OLA no GLPI é a parte fácil - o que parte na operação real é a escalação que nunca dispara. Na manutenção de ambientes GLPI de clientes, o pedido que mais chega não é "como crio um SLA", mas sim "configurei tudo e ninguém é avisado quando o prazo estoura". Este guia configura SLA e OLA no GLPI 11 de raiz e mostra as consultas SQL que usamos para diagnosticar porque é 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: "os chamados de prioridade alta são respondidos em 1h e resolvidos em 4h".

OLA (Operational Level Agreement) é o acordo interno entre as equipas que sustentam esse SLA. Exemplo: "a infraestrutura responde às escalações do N1 em 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 que está a primeira confusão: escalar para o N2 NÃO pausa o SLA do cliente.

Como o GLPI modela o SLA e o OLA por dentro

Perceber o modelo de dados evita a maioria dos erros de configuração. No GLPI, o SLA e o 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 chapéu de 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 a 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 no ecrã; fecha na primeira atribuição ou no primeiro acompanhamento - é o que o GLPI grava em takeintoaccount_delay_stat.

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

Prazo até à solução do chamado.

Passo a passo: configurar o SLA no GLPI 11

1. O calendário primeiro. Antes do SLA, defina o calendário de atendimento (Configuração > Calendários) com os segmentos de horário reais (ex.: seg-sex, 08:00-18:00). Se o SLM ficar sem calendário (calendars_id = 0), o GLPI conta 24h seguidas; com calendário, conta só horas úteis.
2. Crie o SLM e associe o calendário. É o contentor que agrupa os SLA e OLA do serviço.
3. Crie um SLA por prioridade, um para o TTO e outro para o TTR. Use a matriz abaixo como ponto de partida.
4. Atribua por 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 a 75%, 100% e 150% do prazo).

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

Configurar o OLA

O OLA segue a mesma estrutura (TTO/TTR mais níveis de escalação), mas mede o compromisso interno entre equipas. 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. A repetir o ponto que mais dúvidas gera: o OLA não congela o SLA.

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

Na manutençã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 percorre os níveis de escalação, está em modo interno (só corre 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 é executado. Por isso, na nossa checklist de implementação, verificar o slaticket vem ANTES de criar qualquer nível de escalação.

Garanta o GLPI cron a correr 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 na base de dados que a ação está viva e em modo externo:

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

E a consulta que corremos no dia a dia da manutenção: chamados com prazo de resolução já ultrapassado e ainda abertos.

-- Chamados com TTR vencido e ainda não resolvidos.
-- status: 5 = resolvido, 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 apanhar o SLM sem calendário antes que ele parta os prazos):

-- SLAs configurados e o calendário herdado do SLM.
-- calendario NULL/vazio = contagem 24h seguidas (a 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 equipa 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 estados ou prazos em massa por SQL: contorna o recálculo do tempo de espera (sla_waiting_duration) e o prazo fica errado.
• Documente que regra de negócio atribui cada SLA - regra órfã é a segunda maior causa de "SLA não aplicado".

Próximo passo

Com o SLA e o OLA no ar, monte o seu 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 a semana, a manutenção de GLPI da NexTool assume a configuração, o cron e a monitorização dos prazos por si.

Revisto pela equipa NexTool Solutions.